Category: Angular

Signals custom equality functions

Alain Chautard

Angular Signals are growing almost every day with new features and new ways of building Angular applications. If you’re still unsure about signals and want to catch up, you can watch this Angular Signals workshop recording on Youtube or sign up for my continuously updated Angular Signals course.

Today, let’s explore how Angular determines if the value of a signal has changed. If we create the following signal with a default value of “Hello”:

Then calling name.set("Hello") does not trigger any updates for any of the consumers of our name signal. That’s because Angular compares the “new” value with the previous one using a === comparison, and "Hello" === "Hello" is true, so Angular doesn’t trigger any change.

What about objects? When comparing objects with ===, we’re comparing references, meaning “Are the two variables pointing at the same object?” We can verify that easily with a few lines of Javascript running in a browser console:

This leads us to the custom signal equality function. If we want to do a deep comparison instead of just comparing references, we can instruct Angular to do so by providing our own comparison function. Here is the example used by the Angular team:

Of course, we don’t need lodash to implement custom equality functions. For example, we want to create a signal that only emits updates when the current user ID changes. We don’t care if the user’s name or email changes, just the ID (which would indicate that a new user logged in, most likely):

With this approach, the signal doesn’t trigger any updates if we change values that aren’t the ID. For instance, we can secretly turn our user into Batman (and note that I do create a new object by making a copy of the current one, which would make === return false):

And yet my user remains known as Bruce after turning him into Batman (full example here on Stackblitz):

Why use custom equality functions?

Performance could be one thing: if we have a signal that stores an object and know that the only change we make to that object is one or two specific properties, then creating a custom equality function on these properties would make perfect sense. Even more so if the properties are in nested objects, though I wouldn’t recommend using deeply nested objects as signal values, keeping our values as flat as possible instead.

How to use Angular Router State?

Alain Chautard

The Angular Router supports passing custom state information with every navigation. Here is an example of using routerLink with some attached state:

As you can see, state is an @Input of the routerLink directive. You can pass any number of objects you want to that state. Such a state gets added to the browser’s history.state object, which can be helpful if you need to pass some information to a non-Angular library, for instance.

The receiving component can access the data using router.getCurrentNavigation(). The state data is then nested under extras.state:

You can find an example in action here on Stackblitz. The example is an app with a list of products. Clicking on a product opens a product details component. The selected product is passed to such component using router state instead of using a resolver and URL parameters, which leaves our router config lightweight:

The end result looks like this:

What’s an Angular view?

Alain Chautard

As Angular developers, we’re used to thinking of our application as made up of different components. The funny thing is that from the perspective of the Angular team (and compiler), an Angular application is made up of views.

What’s the difference?

The Angular documentation says it best: A view is the smallest grouping of display elements that can be created and destroyed together. Angular renders a view under the control of one or more directives (remember that a component is a specific kind of directive with an HTML template).

In other words, every component creates its own view, and such a view can be made of other views. For instance, when you use a structural directive such as ngIf or ngFor, you’re creating a new view.

Why does it matter?

Because of Signals. The Angular team is working hard on signal-based components for several reasons, one of them being improved change detection that will apply at the view level instead of the component level. This means that when we use signal-based components, the granularity of change detection will be significantly more accurate.

Say, for instance, you have a component with 100 lines of HTML code in its template, and two lines in that template get displayed conditionally based on the value of a signal. With the signal-based approach, changing the value of that signal will result in Angular trying to render just those two lines of the HTML template impacted by the signal update and not bothering about the other 98 lines of code.

When compared to the current default Zone.js change detection, which would check the entire component tree for changes, you can see how massive a difference signal-based components will make. That is why I keep making the point that everyone should be migrating to signals. They are a true game changer for the performance and maintainability of our Angular applications.

Understanding Angular/Typescript types

Alain Chautard

First, some news: I’m running a public 5 half-day online Angular class during the week of April 22nd. It’s the perfect class if you’re new to Angular or have some experience and want to ensure you know about all the fundamentals. It’s the ideal class to prepare for the Angular Level 1 certification exam.

On a side note, I can give private talks for your company or dev team on any topic, including Signals, the future of Angular, and more. Just email me for more info if you’d like to get such a talk planned in the future.

Today, I want to cover a tricky topic for many developers I interact with: Reading and understanding Typescript type definitions from the Angular framework.

For instance, let’s look at the type definition of the canActivate function:

We can tell CanActivateFn is a function because:

  1. The Angular team uses the Fn suffix as a convention for all functions
  2. The type signature is ( params ) => returnType, which is how TypeScript defines types for functions. The arrow symbol => is key there.

So, in that case, the function has two parameters, route of type ActivatedRouteSnapshot, and state of type RouterStateSnapshot. The function returns a type MaybeAsync<GuardResult>.

Here is what the type definition of MaybeAsync looks like:

What does that mean? MaybeAsync<T> is a generic type, which means it works with any number of types, referred to as T here. You can see T as a type variable that gets replaced with an actual value decided when we use that type. For instance, if I end up using MaybeAsync on a string, T becomes string, and our type definition means:

type MaybeAsync<string> = string | Observable<string> | Promise<string>

So MaybeAsync<string> can be either a string, an Observable that will return a string, or a Promise that will return a string. That’s because the | character defines a union type and can be seen as a logical OR. In other words:

MaybeAsync<string> IS A string OR Observable<string> OR Promise<string>.

Now, in the case of our CanActivate function, the return type is MaybeAsync<GuardResult>. On angular.io, most types are clickable (a lot less on angular.dev for now). If I click on GuardResult on this page, I get to the following documentation entry:

So a GuardResult is either a boolean or a UrlTree. This tells us that a CanActivate function can return six possible different types:

  • a boolean, an Observable of a boolean, a Promise of a boolean
  • a UrlTree, an Observable of a UrlTree, a Promise of a UrlTree.

In the past, the documentation would list the six types inline as follows, which is the same thing but a little harder to read. Additional types have been added in Angular 16 to improve the readability of such framework APIs:

Another tricky thing with types is that several features of the Angular framework support different options, resulting in multiple types of signatures. You can look at the toSignal function for such an example – there are 5 different overloads in that function signature, the most basic one being:

As an exercise, I invite you to examine the 5 overloads and try to understand where they come from and why they make sense.

If you encounter any other tricky type you can’t decipher, please send it my way, and I’ll be happy to cover it in a future newsletter entry.

Recap of ng-conf 2024

Alain Chautard

Ng-conf 2024 wrapped up a few hours ago, and the event was filled with great news for Angular enthusiasts. First, the forecast for the following few versions looks very bright:

The Angular team went on to reveal more of these expected features by showing what they’re currently working on:

For the first time, the team also mentioned a future where Angular would run “without Zone.js and RxJs.” Though we knew that zoneless was in the plans for quite some time, it looks like the very positive reception of Angular Signals has pushed the team to envision removing RxJs as a dependency.

The surprising Wiz announcement

On that same topic of Angular Signals, the Angular team made a surprise announcement of their close collaboration with Wiz, a framework used internally at Google for most public apps that everyone knows about: Youtube, Google Photos, Drive, Gmail, etc. That collaboration started with signals, which are shared between Wix and Angular. The big announcement was that Angular Signals are now used in 100% of Youtube, which is quite impressive considering that some people were thinking that Angular was dead not too long ago.

On that same topic, the Angular team revealed their internal motto: build Angular for the next ten years and ensure that it is still an excellent choice ten years from now. Now that sunny forecast makes perfect sense!

Server-side rendering is all the rage

37% more apps have been using server-side rendering since the launch of Angular v17. It’s the topic I talked about at the conference and will be the topic of one of my upcoming free monthly online workshops. In the meantime, you can read my Angular server-side rendering tutorial here.

The great news is that the Angular team is working with Wiz on that topic as well to implement partial hydration soon, which will give us more options on server-side rendering and lazy-loading with defer.

Component authoring improvements

The Angular team is also working on improving the Angular component syntax by possibly removing a lot of boilerplate:

No more selector, no more imports array, no more standalone: true! Again, this is just an idea at this point, but let’s remember that signals were a similar idea not too long ago and are now a fully available API in the framework.

As a recap, there’s much to be excited about for us Angular developers. I will cover more updates in this newsletter over the next few weeks, as there is more to unpack from these two conference days.

You can watch a replay of the main keynote here on YouTube (powered by Angular Signals!)

Code challenge #3 solution

Alain Chautard

Before I dive into the solution of code challenge #3, I wanted to mention that my next FREE workshop is scheduled for April 4th. It will be all about getting into RxJs from scratch, and you can register here. I’ll start from the basics and move on to more advanced topics, such as subjects and operators, and you’ll be able to ask me questions as we go through the content and exercises together.

As always, it’s a free workshop, but your coffee donations are always welcome.

Let’s get into our code challenge solution. The goal was to “connect” two different dropdowns so that the selection of the first dropdown (a continent) would update the contents of the second dropdown (a list of countries for that continent):

The challenge is that countries depend on two different Observable data sources:

  1. An HTTP request to an API to get the list of all countries in the world
  2. The currently selected continent (a reactive form select dropdown)

In other words, we start with the following code:

Our goal is to combine data from both Observables into one result. Ideally, such a result would be updated whenever any of the Observable sources are updated (e.g., a new continent is selected by the user, or a new list of countries is available from the API).

As a result, we can use the withLatestFrom operator to make that “connection” between our two Observables:

Such an operator returns an array of all the latest values of our source Observables in the order in which they were declared. As a result, we can use the map operator to receive that array and turn it into something different:

Inside that operator, we decide to return a new array. The continent remains the same, and we filter the list of countries based on that continent:

FInally, we can use tap to run some side effects. In our case, we update the list of countries used by the dropdown, and we set the country dropdown value to the first country of that list to ensure that a country from a previous continent doesn’t remain selected:

And that’s it! You can see that code in action on Stackblitz here.

A few of you sent me their own solutions to the challenge, and a recurring theme was that most of you didn’t “connect” the Observables and just assumed that the list of countries would already be downloaded and available by the time the user selected a continent. Something along those lines, where this.countries would be received from the API before that code runs:

While the above code would work most of the time, if a user selects a continent before this.countries is defined, an error would be thrown and the corresponding subscription destroyed, which means the above code would not run anymore when the user selects a new value. As a result, using operators is safer.

Another trick in my solution is that I didn’t use any .subscribe in my code, which means I don’t have to unsubscribe, as I let the async pipe do so for me automatically:

That’s it for code challenge #3! Next week, I’ll send you updates from ng-conf in Salt Lake City. If you’re around, feel ree to come say hi!

Code challenge #3: RxJs Wizardry

Alain Chautard

It’s been a few months since our last code challenge, where the goal is to have you look at some code that isn’t working and make you improve your Angular skills along the way.

In this code challenge #3, we have two select dropdowns that have to work together so that when we select a continent, we can only see countries from that continent in the second dropdown. The current code isn’t working – Argentina isn’t in Europe, so this selection should not be possible:

You can fork that code from Stackblitz here. Feel free to email me your solution once you have one ready. I’ll send you a possible solution in next week’s newsletter.

In case you missed my previous code challenges, here they are, along with the link to their respective solutions:

viewChild() and contentChild() for signal-based queries

Alain Chautard

After introducing model() for signal-based 2-way bindings, let’s dive into viewChild() and contentChild() for signal-based queries.

In case you’re not familiar with Angular queries, they existed before Angular 17.2 as the @ViewChild and @ContentChild decorators.

ViewChild is a way to get a reference on an HTML within the current component’s template. For instance, if we need our Typescript to access the instance of a given child component, I can use @ViewChild like so:

The new syntax gives us the same feature as a Signal:

The same goes with ContentChild. The difference between ViewChild and ContentChild is that ViewChild looks for an element inside the component’s template, whereas ContentChild looks for an element projected by the parent component into the ng-content element of the current component using content projection. You can learn more about content projection with this tutorial:

The above code will look for an element with a template reference variable called test in the projected ng-content.

We can achieve the same feature with the new contentChild() function, which returns a Signal:

Differences between these new functions and the old decorators

These new functions bring a few extra interesting features. For instance, we can get rid of possibly undefined values by making a query required:

Decorator-based queries were satisfied once the component was fully initialized, which means that running side effects required the use of specific lifecycle methods:

With signal-based queries, we receive a signal so we can rely on computed() or effect() to run such side-effects:

This approach is less intrusive and requires knowing just one thing: Signals! No more lifecycle methods are needed. You can find these different examples in action on Stackblitz here.

model() for signal-based 2-way data bindings

Alain Chautard

Angular 17.2 brought more features to the signal-based components approach, where almost everything in our components will become signals. We’ve already covered that inputs can be signals since Angular 17.1.

As an Angular developer, you’ve probably used ngModel in the past to create two-way data bindings. You might have created your own 2-way bindings using the approach covered in this tutorial, too.

All of that becomes even easier with Angular 17.2, as we can now do the following using the model function:

The above syntax means that we can pass a value to NameEntryComponent‘s age property as follows:

We can even have a 2-way binding (meaning something that acts as both an input and an output) by using the “banana in a box” syntax as follows:

This gets even better as we can specify that a value is required for that model input using model.required:

Since age and firstName are signals, we can update their values using set or update:

Where increaseAge is a method that uses an arrow function (as those aren’t supported in Angular templates):

You can see this example in action on Stackblitz here.

We can pass data to models using regular component properties:

But it gets even better as we can also use signals as-is with these 2-way bindings:

You can see this new example in action on Stackblitz here. Next week, I will cover 4 more functions available since Angular 17.2, all signal-based as well!

All about environment variables with Angular

Alain Chautard

Angular apps created with the Angular CLI used to have automatic environment creation built-in for new projects. While this automation was removed in recent years to simplify the learning curve of Angular, it is still possible to add support for different environments using the command:

ng generate environments

Before we generate such environments, it’s important to take a look at angular.json in the root folder of any Angular project, more specifically, the section called configurations in the build section:

This tells us that our project has two different configurations: production and development, and the default config for the ng build command is production.

Note that the serve section of angular.json has a similar config that extends the build targets and overrides the default configuration by making it development, which, as a result, is what we use when we run ng serve:

If we want to override the default configurations when running ng serve or ng build, we can do this by adding a configuration flag to the command and making it point to the proper configuration name, for instance:

ng serve --configuration=production

ng build --configuration=development

How do we plug environment variables into this?

When we run ng generate environments, the Angular CLI does two things:

It creates two new files in src/environments: environments.ts (the environment for production, which is also the default) and environment.development.ts for development.

angular.json gets updated with the following highlighted syntax:

As you can see, this instructs the builder to replace the production environment file with the development file when we use the --configuration=development flag.

Such environment files can contain any environment variables we want. For instance, say I want to define a SERVER_URL that is different for production and development. I can do that:

Now, to use such environment variable in my code, all I need to do is import it as follows:

Important: The import has to be from /environments/environment. Angular will pick the correct configuration based on the flag given to the build or serve command.

How do you create environments for QA, pre-prod, and more?

Now that we know that angular.json is the file where all this magic happens, if we want to create a qa environment, we can head to the configurations section of build, add a new configuration block with the name q (or anything you want, of course), and make the file replacement to a new file that I call environment.qa.ts:

Then, I can create that environment file under src/environments and add any variables I need in it:

And that’s it! We covered how to create environment variables for production and development and how to create other custom environments we might need.