Angular

What's new in Angular v12

May 19, 2021

8 min read

Angular 12 Released

Angular v12 has been released! Here are some main updates.

Nullish coalescing operator support

@Component(){
  selector: 'app-comp',
  template: `<div>Hello, {{title ?? 'Angular'}}</div>`
})

Core

APP_INITIALIZER now supports Observable.

It is also a long-waited feature request: in Angular v12, we can now use Observable as APP_INITIALIZER.

import { APP_INITIALIZER } from '@angular/core';

function observableInitializer() {
  // Before Angular v12, you have to return a Promise.
  // return () => someObservable().toPromise();
  // Now you can return the observable directly.
  return () => someObservable();
}

@NgModule({
  imports: [...],
  providers: [{
    provide: APP_INITIALIZER,
    useFactory: observableInitializer,
    multi: true
  }],
  ...
})
export class AppModule {}

Http

HttpClient

Before Angular 12, if you wanted to pass boolean or number as HttpParams, you had to:

HttpClient.get('api/endpoint', { param1: '10', param2: 'true' })

With Angular 12, the HttpParams has been updated to accept the boolean and the number values:

HttpClient.get('api/endpoint', { param1: 10, param2: true })

Http Interceptor Context

This is a very long waited feature. In Angular 12, you can now pass data between interceptors. Here is a great article by Netanel Basal.

Form

Form: Support min/max validator

HTML5 standards support built in validator such as min/max for input element.

<input type="number" min="5" max="10">

Before Angular 12, the min/max attributes are ignored by FormsModule, so the Angular FormControl valid property will still be true even the input data exceed the min or max range. But the underlying DOM HTMLInputElement's validity.valid will still be false.

From Angular 12, the min/max validator is implemented so the valid result will be consistent with native DOM status.

Animation

Sometimes we want to disable animations. Before Angular 12, we needed to provide the NoopAnimationModule. In Angular 12, there is a new way to do that by using BrowserAnimationsModule.withConfig({disableAnimations: true}) so the user can disable animations based on the runtime information.

Router

Router: Support location.historyGo() functionality.

Support location.historyGo(relativePosition: number) to navigate to the specific history page so it will be compatible with the DOM history.go() API.

Router: Provides RouterOutletContract interface

Provides RouterOutletContract interface allows the 3rd party library to implement its own RouterOutlet more easily (such as add own logic for navigation, animation). For details, please refer to this PR https://github.com/angular/angular/pull/40827.

Tooling

Angular Linker

Ivy has been released from Angular 9 and has become the default in the Angular App from Angular 10. It is fast, easy to debug, and has a lot of possibilities in the future. However, for Angular library development, the user still has to compile the lib with the old ViewEngine to publish to npm. The Angular library deploy process is:

The developer compiles the lib with ViewEngine.
When the Angular app is using the lib, when yarn install, Angular compiler will travel the node_modules directory and use ngcc to convert the ViewEngine library to Ivy. This process is slow and needs to run whenever node_modules changes.

The reason we need this process is if we remove ngcc and publish the Ivy instructions to npm, the instruction code will become the public API. It is very difficult to change it in the future. ViewEngine is not instruction but metadata, so it can be used across multiple versions even for Ivy.

To resolve this issue, Angular provides an RFC last year, https://github.com/angular/angular/issues/38366, with an idea which is Angular Linker. It is an advanced version ngcc. It compiles the Angular library code with partial mode.

The output is not Ivy instructions, so it allows future changes.
The output is still metadata, but not like ViewEngine, the metadata is self-contained, so the output for one component contains all the information needed to compile this component without any other global knowledge(such as NgModule). It is fast and be able to do incremental/cache/parallel build.
The new intermediate output can be directly consumed by Angular Compiler, so the node_modules folder doesn't need to be touched.

To use this feature, update the option in the tsconfig.lib.prod.json like this.

"enableIvy": "true", "compilationMode": "partial"

Typescript 4.2 support

Supports Typescript 4.2.

E2E protractor RFC

Angular is using protractor for e2e test. The protractor has a long history from 2013. It helped users write e2e test, and to support better async test, protractor did a lot of work via ControlFlow to make async/await work.

Since the native async/await is introduced into Javascript standard, protractor ControlFlow becomes incompatible with the native async/await, so protractor drops the ControlFlow and uses the solution of selenium-webdriver completely.

Also protractor has a lot of features just for AngularJS such as locator/mock. After removing these codes, protractor becomes a wrapper of selenium wrapper without any valuable functionalities.

And now the Angular developers are using several alternative solutions to do the e2e test such as:

Cypress
PlayWright
Puppeteer

The Angular team posts an RFC to deprecate the protractor and make Angular easy to integrate with the 3rd party e2d platform.

Here is the RFC https://github.com/angular/protractor/issues/5502

Based on the RFC, Angular plans to drop the protractor support until Angular v15 and will guide the Angular developers to select an alternative platform when the user tries to run ng e2e.

CLI: Webpack 5 support

Webpack 5 support many new features such as:

Module federation is a new way to develop micro-frontend
Disk caching for faster build
Better tree shaking

CLI: Lint

Angular v11 deprecated to use TSLint as the default linter, and Angular v12 remove TSLint and codelyzer from cli, so please reference the following article to migrate to eslint. (https://github.com/angular-eslint/angular-eslint#migrating-from-codelyzer-and-tslint)

CLI: Build

When we build an Angular app, we use ng build --prod all the time. The options often confuse the user that --prod will make a production build, but it is just an alias of ng build --configuration=production. To make this more clear, CLI remove --prod and add a defaultConfiguration setting with the value production. Now, ng build default will build with production configuration.

CLI: Build bundles with ES2017+

Until Angular 12, Angular only supports output bundles in ES2015 format. ES2017+ is not supported because Zone.js is not supporting native async/await patching. From Angular 12, CLI supports to only transpile the native async/await code to Promise but keep the other ES2017+ code untouched, so you can specify the output bundle format to ES2017+ from Angular 12.

CLI: `inlineCritical` by default

The inlineCritical settings of styles optimization in the angular.json becomes true by default. Please reference here for more details.

CLI: `strict` mode by default

The workspace generated by CLI will use strict mode by default. To generate non-strict mode, use --no-strict option.

CLI: Built in `tailwindcss` support

Tailwindcss is a popular CSS library. Before Angular 12, to integrate with Tailwindcss, the user needs to do some postcss configuration themselves. With Angular 12, this is done by the CLI so it is super easy to do the integration.

npm install -D tailwindcss npx tailwindcss init

This is the same process to install the normal Tailwindcss.

CLI: confirm `ng add` before install packages from npm.

Now ng add will ask the user to confirm the package/version before installing the packages. This gives the user a chance to stop the process when the user has a typo in the project name or want to initialize the project with other options.

Angular Language Service for Ivy

Angular Ivy has been released since v9, but the Angular Language Service is still using View Engine to compile the template and did a lot of magic work to make everything work in Ivy, which is not efficient. Also, since View Engine is deprecated, some issues and features may not be implemented in the View Engine version of Language Service for Ivy.

Now we have the new Angular Language Service written in Ivy and for Ivy.

You can opt-in the new Angular Language Service beta with Ivy support now. To use it in VSCode, try the following steps.

Install the latest extension in the VSCode Marketplace
Set strictTemplates: true in tsconfig.json Angular compiler options
Go to Preferences -> Settings -> Extensions -> Angular Language Service -> Check “Experimental Ivy”

Please reference this blog for more details.

CLI: Support inlineStyleLanguage option

A new build option inlineStyleLanguage is added. Now you can write css/sass/scss/less in the inline style of a component!

Angular Components

MDC Web based new component

Angular Component is continuing to create new MDC Web based components and the backward-compatible. Here is the design.

For the new Angular Material Component, Angular CDK provides the behavior and the MDC Web Component provides the user experiences defined by the Material Design spec. The Angular Material team doesn't need to maintain another implementation of the Material Design and the UI will be more consistent.

New `@use` SASS module system

You may already use the @import syntax in the SASS style file, but it has some flaws and make the module system hard to maintain. For details, please reference the article here.

Now Angular Components are using the new @use syntax for the better module system of SASS. To use the new module system, you can use the following schematic to migrate.

ng g @angular/material:themingApi

Also, the node-sass package will be replaced by the new sass package.

Deprecations

IE11 support is deprecated!
ViewEngine for application build is removed. All applications are using Ivy to build.
entryComponent is removed from Component schematic.
string based lazy loading support is dropped.

{ path: 'Lazy', component: LazyComponent }, { path: 'lazy', loadChildren: './modules/lazy/lazy.module#LazyModule', }

is not supported, please use dynamic import instead.

{ path: 'Lazy', component: LazyComponent }, { path: 'lazy', loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule) }

For the full deprecation list, please check here.

How to update to v12

Use the Angular CLI:

ng update @angular/cli @angular/core

You can find more information from update.angular.io/.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Jia Li

Jia Li is a frontend developer with passion, he is an Angular Collaborator and the code owner of angular/zone.js. He loves Angular and now develops Angular enterprise application.

@JiaLiPassion @JiaLiPassion

You Don't Need NgRx To Write a Good Angular App

NgRx is a great tool that allows you to manage state and side effects in Angular applications in a Redux-like manner. It streamlines state changes with its unidirectional data flow, and offers a structured approach to handling data and side effects. Numerous posts on our blog detail its strengths and affiliated techniques. Some Angular developers even argue that incorporating NgRx is imperative once an app expands beyond two features. While NgRx can undoubtedly enhance an Angular application or library by simplifying debugging, translating business logic into code, and improving the architecture, it does present a steep learning curve. Despite the provocative title, there is some truth to the statement: your app or library may indeed not need NgRx. Surprisingly, I successfully developed a suite of enterprise Angular libraries over five years without involving NgRx. In that project, we decided to opt out of using a state management library like NgRx because of its steep learning curve. Developers with varying levels of Angular expertise were involved, and the goal was to simplify their experience. My bold assertion is that, with careful consideration of architectural patterns, it is entirely possible to develop a robust app or library using only Angular, without any third-party libraries. Employing select design patterns and leveraging Angular's built-in tools can yield a highly maintainable app, even without a dedicated state management library. Having shared my somewhat audacious opinion, let me now support it by outlining a few patterns that facilitate the development of a maintainable, stateful Angular application or library without NgRx. Services and the Singleton Pattern Services provided in root or a module yield a shared instance across the entire app or module, effectively rendering them singletons. This characteristic makes them ideal for managing and sharing state across components without requiring a dedicated state management tool like NgRx. Particularly, for small to medium-sized applications, a "state service" can be a straightforward and effective alternative to a comprehensive state management solution when implemented correctly. To accurately implement state in a singleton service, consider the following: - Restrict state data to private properties and expose them only through public methods or observables to prevent external mutations. Such a pattern safeguards the integrity of your state by averting unauthorized modifications. - Utilize BehaviorSubjects or signals to enable components to respond to state changes. Both BehaviorSubject and SettableSignal retain the current value and emit it to new subscribers immediately. Components can then subscribe to these to receive the current value and any subsequent updates. - Expose public methods in your service that manage state modifications to centralize the logic for updating the state and incorporate validation, logging, or other necessary side effects. - When modifying state, always return a new instance of the data rather than altering the original data. This ensures that references are broken and components that rely on change detection can accurately detect changes. Good Component Architecture Distinguish your UI components into stateful (containers) and stateless (presentational) components. Stateful components manage data and logic, while stateless components merely receive data via inputs and emit events without maintaining an internal state. Do not get dragged into the rabbit hole of anti-patterns such as input drilling or event bubbling while trying to make as many components presentational as possible. Instead, use a Data Service Layer to provide a clean abstraction over backend API calls and handle error management, data transformation, caching, and even state management where it makes sense. Although injecting a service into a component technically categorizes it as a "smart" component, segregating the data access logic into a separate service layer ultimately enhances modularity, maintainability, scalability, and testability. Immutability A best practice is to always treat your state as immutable. Instead of modifying an object or an array directly, you should create a new copy with the changes. Adhering to immutability ensures predictability and can help in tracking changes. Applying the ChangeDetectionStrategy.OnPush strategy to components whenever possible is also a good idea as it not only optimizes performance since Angular only evaluates the component for changes when its inputs change or when a bound event is triggered, but it also enforces immutability. Change detection is only activated when a different object instance is passed to the input. Leveraging Angular Router Angular's router is a powerful tool for managing application state. It enables navigation between different parts of an application, allowing parameters to be passed along, effectively using the URL as a single source of truth for your application state, which makes the application more predictable, bookmarkable, and capable of maintaining state across reloads. Moreover, components can subscribe to URL changes and react accordingly. You can also employ router resolvers to fetch data before navigating to a route, ensuring that the necessary state is loaded before the route is activated. However, think carefully about what state you store in the URL; it should ideally only contain the state essential for navigating to a specific view of your application. More ephemeral states, like UI state, should be managed in components or services. Conclusion Angular provides lots of built-in tools and features you can effectively leverage to develop robust, maintainable applications without third-party state management libraries like NgRx. While NgRx is undoubtedly a valuable tool for managing state and side effects in large, complex applications, it may not be necessary for all projects. By employing thoughtful design patterns, such as the Singleton Pattern, adhering to principles of immutability, and leveraging Angular's built-in tools like the Router and Services, you can build a highly maintainable and stateful Angular application or library....

Sep 1, 2023

4 mins

Angular

Angular 17: Continuing the Renaissance

Angular 17: A New Era November 8th marked a significant milestone in the world of Angular with the release of Angular 17. This wasn't just any ordinary update; it was a leap forward, signifying a new chapter for the popular framework. But what made this release truly stand out was the unveiling of Angular's revamped website, complete with a fresh brand identity and a new logo. This significant transformation represents the evolving nature of Angular, aligning with the modern demands of web development. To commemorate this launch, we also hosted a release afterparty, where we went deep into its new features with Minko Gechev from the Angular core team, and Google Developer Experts (GDEs) Brandon Roberts, Deborah Kurata, and Enea Jahollari. But what exactly are these notable new features in the latest version? Let's dive in and explore. The Angular Renaissance Angular has been undergoing a significant revival, often referred to as Angular's renaissance, a term coined by Sarah Drasner, the Director of Engineering at Google, earlier this year. This revival has been particularly evident in its recent versions. The Angular team has worked hard to introduce many new improvements, focusing on signal-based reactivity, hydration, server-side rendering, standalone components, and migrating to esbuild and Vite for a better and faster developer experience. This latest release, in particular, marks many of these features as production-ready. Standalone Components About a year ago, Angular began a journey toward modernity with the introduction of standalone components. This move significantly enhanced the developer experience, making Angular more contemporary and user-friendly. In Angular's context, a standalone component is a self-sufficient, reusable code unit that combines logic, data, and user interface elements. What sets these components apart is their independence from Angular's NgModule system, meaning they do not rely on it for configuration or dependencies. By setting a standalone: true flag, you no longer need to embed your component in an NgModule and you can bootstrap directly off that component: ` Compared to the NgModules way of adding components, as shown below, you can immediately see how standalone components make things much simpler. ` In this latest release, the Angular CLI now defaults to generating standalone components, directives, and pipes. This default setting underscores the shift towards a standalone-centric development approach in Angular. New Syntax for Enhanced Control Flow Angular 17 introduces a new syntax for control flow, replacing traditional structural directives like ngIf or ngFor, which have been part of Angular since version 2. This new syntax is designed for fine-grained change detection and eventual zone-less operation when Angular completely migrates to signals. It's more streamlined and performance-efficient, making handling conditional or list content in templates easier. The @if block replaces *ngIf for expressing conditional parts of the UI. ` The @switch block replaces ngSwitch, offering benefits such as not requiring a container element to hold the condition expression or each conditional template. It also supports template type-checking, including type narrowing within each branch. ``` The @for block replaces *ngFor for iteration and presents several differences compared to its structural directive predecessor, ngFor. For example, the tracking expression (calculating keys corresponding to object identities) is mandatory but offers better ergonomics. Additionally, it supports @empty blocks. ` Defer Block for Lazy Loading Angular 17 introduces the @defer block, a dramatically improving lazy loading of content within Angular applications. Within the @defer block framework, several sub-blocks are designed to elegantly manage different phases of the deferred loading process. The main content within the @defer block is the segment designated for lazy loading. Initially, this content is not rendered, becoming visible only when specific triggers are activated or conditions are met, and after the required dependencies have been loaded. By default, the trigger for a @defer block is the browser reaching an idle state. For instance, take the following block: it delays the loading of the calendar-imp component until it comes into the viewport. Until that happens, a placeholder is shown. This placeholder displays a loading message when the calendar-imp component begins to load, and an error message if, for some reason, the component fails to load. ` The on keyword supports a wide a variety of other conditions, such as: - idle (when the browser has reached an idle state) - interaction (when the user interacts with a specified element) - hover (when the mouse has hovered over a trigger area) - timer(x) (triggers after a specified duration) - immediate (triggers the deferred load immediately) The second option of configuring when deferring happens is by using the when keyword. For example: ` Server-Side Rendering (SSR) Angular 17 has made server-side rendering (SSR) much more straightforward. Now, a --ssr option is included in the ng new command, removing the need for additional setup or configurations. When creating a new project with the ng new command, the CLI inquires if SSR should be enabled. As of version 17, the default response is set to 'No'. However, for version 18 and beyond, the plan is to enable SSR by default in newly generated applications. If you prefer to start with SSR right away, you can do so by initializing your project with the --ssr flag: ` For adding SSR to an already existing project, utilize the ng add command of the Angular CLI: ` Hydration In Angular 17, the process of hydration, which is essential for reviving a server-side rendered application on the client-side, has reached a stable, production-ready status. Hydration involves reusing the DOM structures rendered on the server, preserving the application's state, and transferring data retrieved from the server, among other crucial tasks. This functionality is automatically activated when server-side rendering (SSR) is used. It offers a more efficient approach than the previous method, where the server-rendered tree was completely replaced, often causing visible UI flickers. Such re-rendering can adversely affect Core Web Vitals, including Largest Contentful Paint (LCP), leading to layout shifts. By enabling hydration, Angular 17 allows for the reuse of the existing DOM, effectively preventing these flickers. Support for View Transitions The new View Transitions API, supported by some browsers, is now integrated into the Angular router. This feature, which must be activated using the withViewTransitions function, allows for CSS-based animations during route transitions, adding a layer of visual appeal to applications. To use it, first you need to import withViewTransitions: ` Then, you need to add it to the provideRouter configuration: ` Other Notable Changes - Angular 17 has stabilized signals, initially introduced in Angular 16, providing a new method for state management in Angular apps. - Angular 17 no longer supports Node 16. The minimal Node version required is now 18.13. - TypeScript version 5.2 is the least supported version starting from this release of Angular. - The @Component decorator now supports a styleUrl attribute. This allows for specifying a single stylesheet path as a string, simplifying the process of linking a component to a specific style sheet. Previously, even for a single stylesheet, an array was required under styleUrls. Conclusion With the launch of Angular 17, the Angular Renaissance is now in full swing. This release has garnered such positive feedback that developers are showing renewed interest in the framework and are looking forward to leveraging it in upcoming projects. However, it's important to note that it might take some time for IDEs to adapt to the new templating syntax fully. While this transition is underway, rest assured that you can still write perfectly valid code using the old templating syntax, as all the changes in Angular 17 are backward compatible. Looking ahead, the future of Angular appears brighter than ever, and we can't wait to see what the next release has in store!...

Nov 20, 2023

6 mins

AngularTypeScriptJavaScript

Build Typescript Project with Bazel Chapter 2: File Structure

Build Typescript Project with Bazel Chapter 2: File Structure In the last chapter, we introduced the basic concept of Bazel. In this blog, I would like to talk about the file structure of Bazel. Concept and Terminology Before we introduce the file structure, we need to understand several key concepts and terminology in Bazel. - Workspace - Package - Target - Rule These concepts, and terminology, are composed to Build File, which Bazel will analyze, and execute. The basic relationship among these concepts looks like this , we will discuss the details one by one. Workspace A "workspace" refers to the directories, which contain 1. The source files of the project. 2. Symbolic links contain the build output. And the Bazel definition is in a file named WORKSPACE, or WORKSPACE.bazel at the root of the project directory. NOTE, one project can only have one WORKSPACE definition file. Here is an example of the WORKSPACE file. ` In a WORKSPACE file, we should 1. Define the name of the workspace. The name should be unique globally, or at least unique in your organization. You could use the reverse dns name, such as com_thisdot_bazel_demo, or the name of the project on GitHub. 2. Install environment related packages, such as yarn/npm/bazel. 3. Setup toolchains needed to build/test the project, such as typescript/karma. Once WORKSPACE is ready, application developers don't really need to touch this file. Package - The primary unit of code organization (something like module) in a repository - Collection of related files and a specification of the dependencies among them - Directory containing a file named BUILD or BUILD.bazel, residing beneath the top-level directory in the workspace - A package includes all files in its directory, plus all subdirectories beneath it, except those which, themselves, contain a BUILD file It is important to know how to split a project into package. It should be easy for the users to develop/test/share the unit of a package. If the unit is too big, the package has to be rebuilt on every package file change. If the unit is too small, it will be very hard to maintain and share. So, this is not an issue of Bazel. It is a general problem of project management. In Bazel, every package will have a BUILD.bazel file, containing all of the build/test/bundle target definitions. For example, here is a of the Angular structure. Every directory under packages directory is a package of code organization, and also the build organization of Bazel. Let's take a look at the file structure of gulpjs in Angular, so we can have a better understanding about the difference between Bazel and gulpjs. ` In most cases, - a gulpjs file doesn't have 1:1 relationship to the package directory. - a gulpjs file can reference any files inside the project. But for Bazel, - Each package should have their own BUILD.bazel file. - The BUILD.bazel can only reference the file inside the current package, and if the current package depends on other packages, we need to reference the Bazel build target from the other packages instead of the files directly. Here is a Bazel Package directory structure in Angular repo. Build File Before we talk about target, let's take a look at the content of a BUILD.bazel file. ` The language of the BUILD.bazel file is Starlark. - Starlark is a subset of Python. - It is a very feature-limited language. A ton of Python features, such as class, import, while, yield, lambda, is, raise, are not supported. - Recursion is not allowed. - Most of Python's builtin methods are not supported. So Starlark is a very very simple language, and only supports very limited Python syntax. Target The BUILD.bazel file contains build targets. Those targets are the definitions of the build, test, and bundle work we want to achieve. The build target can represent: - Files - Rules The target can also depend on other targets - Circular dependencies are not allowed - Two targets, generating the same output, will cause a problem - Target dependency must be declared explicitly. Let's see the previous sample, ` Here, ts_library is a rule imported from @npm_bazel_typescript workspace, and ts_library(name = "lib") is a target. The name is lib, and this target defines the metadata for compiling the lib.ts with ts_library rule. Label Every target has a unique name called label. For example, if the BUILD.bazel file above is under /lib directory, then the label of the target is ` The label is composed of several parts. 1. the name of the workspace: @com_thisdot_bazel_demo. 2. the name of the package: lib. 3. the name of the target: lib. So, the composition is //:. Most of the times, the name of the workspace can be omitted, so the label above can also be expressed as //lib:lib. Additionally, if the name of the target is the same as the package's name, the name of the target can also be omitted. Therefore, the label above can also be expressed as //lib. NOTE: The label for the target needs to be unique in the workspace. Visibility We can also define the visibility to define whether the rule inside this package can be used by other packages. ` The visibility can be: - private: the rules can be only used inside the current package. - public: the rules can be used everywhere. - //some_package:package_scope: the rules can only be used in the specified scope under //some_package. The package_scope can be: pkg/subpackages/package group. And if the rules in one package can be accessed from the other package, we can use load to import them. For example: ` Here, we import the ts_library rule from the Bazel typescript package. Target - Target can be Files or Rule. - Target has input and output. The input and output are known at build time. - Target will only be rebuilt when input changes. Let's take a look at Rule first. Rule The rule is just like a function or macro. It can accept named parameters as options. Just like in the previous post, calling a rule will not execute an action. It is just metadata. Bazel will decide what to do. ` So here, we use the ts_library rule to define a target, and the name is lib. The srcs is lib.ts in the same directory. The visibility is public, so this target can be accessed from the other packages. Rule Naming It is very important to follow the naming convention when you want to create your own rule. - *_binary: executable programs in a given language (nodejs_binary) - *_test: special _binary rule for testing - *_library: compiled module for a given language (ts_library) Rule common attributes Several common attributes exist in almost all rules. For example: ` - name: unique name within this package - srcs: inputs of the target, typically files - deps: compile-time dependencies - data: runtime dependencies - testonly: target which should be executed only when running Bazel test - visibility: specifies who can make a dependency on the given target Let's see another example: ` Here, we use the data attribute. The data will only be used at runtime. It will not be analyzed by Bazel at build time. So, in this blog, we introduced the basic Bazel structure concepts. In the next blog, we will introduce how to query Bazel targets....

Mar 30, 2020

6 mins

Bazel

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

Angular 12 Released

Nullish coalescing operator support

Core

APP_INITIALIZER now supports Observable.

Http

HttpClient

Http Interceptor Context

More readable Http status code

Form

Form: Support min/max validator

Animation

Router

Router: Support location.historyGo() functionality.

Router: Provides RouterOutletContract interface

Tooling

Angular Linker

Typescript 4.2 support

E2E protractor RFC

CLI: Webpack 5 support

CLI: Lint

CLI: Build

CLI: Build bundles with ES2017+

CLI: inlineCritical by default

CLI: strict mode by default

CLI: Built in tailwindcss support

CLI: confirm ng add before install packages from npm.

Angular Language Service for Ivy

CLI: Support inlineStyleLanguage option

Angular Components

MDC Web based new component

New @use SASS module system

Deprecations

How to update to v12

Jia Li

You Don't Need NgRx To Write a Good Angular App

Angular 17: Continuing the Renaissance

Build Typescript Project with Bazel Chapter 2: File Structure

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You Don't Need NgRx To Write a Good Angular App

Angular 17: Continuing the Renaissance

Build Typescript Project with Bazel Chapter 2: File Structure

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

CLI: `inlineCritical` by default

CLI: `strict` mode by default

CLI: Built in `tailwindcss` support

CLI: confirm `ng add` before install packages from npm.

New `@use` SASS module system