Running initialization code when Angular loads + router data updates

I’m posting a few essential articles to revisit, updates to know about, and one question to ponder this week:

Three articles to revisit and associated updates with Angular 19

When we need to initialize an application with server data (environment variables, for instance), we can use Angular’s APP_INITIALIZER. For more information, revisit this tutorial about APP_INITIALIZER.

Angular 19 introduced a new syntax for this feature. This function must be called in the array of providers of your app bootstrap as follows:

You can return an Observable or a Promise from your init function. The official documentation is here.

Another interesting feature expanded in recent versions is the ability to pass data to components using the router. I wrote about router state and how to use resolvers in the past, and even how to map router data to component inputs.

With Angular 19, we can pass data to a RouterOutlet to share information between parent and child components as follows:

One question to ponder this week:

How do you pass data to your routed components? Do you use any of the features described above or just inject services in the routed component? Is there anything you could improve in your architecture using these tools?

Angular 19: Standalone updates

Angular 19 is a massive release with lots of improvements and new features. I covered all signal-related updates earlier. Today, let’s focus on what’s changed with standalone features in the framework.

First, standalone is the new default! In Angular 19, you don’t need the standalone: true option in your decorators, that’s the default value now. Instead, you want to use standalone: false for features that are not standalone and belong to a ngModule.

When you upgrade to Angular 19, ng update will automatically remove standalone : true where you use it and use standalone: false where needed. No need to worry about it!

Second, the Angular compiler will warn you when you have unused imports in your standalone components. This is great to help keep your code clean:

TS-998113: Imports array contains unused imports [plugin angular-compiler]

src/app/user/users.component.ts:9:27:
9 │ imports: [UserComponent, UnusedComponent],Code language: HTTP (http)

Finally, if you want to make sure all your components are standalone, you can use the new "strictStandalone": true option in the angularCompilerOptions.

Then, if your create a non-standalone feature, you’ll get an error:
TS-992023: Only standalone components/directives are allowed when 'strictStandalone' is enabled.

What do you want from this newsletter in 2025?

There are only a month and a few days left in 2024, and my goal is to keep publishing weekly updates until the end of the year. By the time you read this, it will be Thanksgiving in the United States, a time of the year when we are thankful and spend time with our families.

First, I want to thank you for reading this newsletter; I hope you find it useful. It certainly has become quite a database of resources for me, at the very least, and I use these posts all the time when training and mentoring people.

Now, I’d like to know what you think of the new format I have used a few times lately (example here) compared to the “old” format (example here). What I like about the new format is that I suggest essential topics to revisit rather than covering just new features and tutorials on specific topics. It’s more broad as a result, and there are probably more interesting topics every week.

In any case, if you’re thankful for this newsletter or have any feedback or ideas to share, let me know. I read and respond to every email.

Happy Thanksgiving if that’s something you’re celebrating, and since Thanksgiving is followed by Black Friday, you can get up to 54% off any certification and training package at certificates.dev!

What’s new with Signals in Angular 19?

Angular 19 is now available with many different updates. A video recap (23 minutes long) of all these features is available on YouTube.

There is a lot to unpack, so this week, my focus is on all signal-related updates.

First, signal-based input, output, and view query functions are all stable APIs as of v19, which means you can use all of them safely. Here is the complete list of such stable features:

input()output()model()viewChild()viewChildren()contentChild(), contentChildren()takeUntilDestroyed()outputFromObservable(), and outputToObservable() 

Yes, that’s a lot!

Second, to help you migrate your old @Input() and @ViewChild()to their signal-based equivalents, new Angular CLI migration commands are available:

ng generate @angular/core:signal-input-migration
ng generate @angular/core:signal-queries-migration
ng generate @angular/core:output-migration

Initial feedback from these automated migrations is very positive.

The third update, a new type of Signal (in developer preview) called linkedSignal. This new function also creates a computed signal that can be written manually. In other words, a computed signal is read-only, whereas a linkedSignal is writable while preserving automatic update and computation features of a computed signal.

The final and most significant update is the addition of a resource API to Angular. This is a big one for several reasons: It enables total signal-based reactivity while using Promises or RxJs to fetch updates.

Here is a code example:

sortOrder = signal<'asc' | 'desc'>('asc');
usersResource = rxResource({
request: () => ({ sort: this.sortOrder() }),
loader: ({ request }) => this.http.get('/users', { params: { sort: request.sort } })
});

The above code will send a request to /users with the proper sort parameter every time the sortOrder() signal value changes. The result is an object with lots of information about the resource:

The approach is similar to ngx-signalify or TanStack Query, and it looks promising. Now, resource is in an experimental state, which means “do not use it in production yet” (the API will likely change), but you can learn more about it here. Because there’s so much more to it, I’ll write a dedicated post and/or do a long-form video workshop on that topic.

And that’s it for the four main updates regarding Signals in v19. I could add a fifth one with the effect() function still in developer preview but now allows writing other signals by default (no more need to add the option to perform such writes).

Angular 19 released next week!

This week, we get back to the new format of the newsletter. I’m posting a few essential articles to revisit, updates to know about, and one question to ponder:

Three short articles to revisit:

  • If you subscribe to Observables within another subscription, you’ll want to read this as it’s an anti-pattern. The solution is to use the switchMap operator or another equivalent, such as mergeMap.

Two Angular updates:

One question to think about:

Do your prefer Template driven forms or reactive? What about none of that? Have you ever considered that option?

RxJs tips and new resource API

In the new format of this weekly newsletter, I’m posting a few essential articles to revisit, updates to know about, and one question to ponder this week:

Three short articles to revisit:

If you haven’t adopted the takeUntilDestroyed operator, read this short tutorial about it. It’s even better than using the async pipe with @let or other automated unsubscription techniques.

Two updates to know about:

One question to think about:

Do you always unsubscribe from RxJs Observables? If you don’t, here are a few reasons why you should do it. Then refer to my 3 short articles above to see how you could do it both easily and consistently.

Standalone, SSR, and more!

In the new format of this weekly newsletter, I’m posting a few essential articles to revisit, updates to know about, and one question to ponder this week:

Three short articles to revisit:

  • Standalone components as they’re about to become the default in Angular 19. No more standalone: true will be needed, true will be the default value, and automatic migrations will add standalone: false to module-based components.
  • Look at the standalone components cheat sheet for an overview of all standalone-related features, including lazy-loading.
  • What you need to know about ngModules and why they don’t really matter anymore.

Two updates to know about:

  • Incremental hydration update from the Angular team on YouTube. This is only for server-side rendering, but I’d suggest you take a look anyway, as this video has some cool stuff.
  • The Angular Senior Certification Exam (aka level 3) is now live again! No more final interviews are needed, but two challenging coding exercises will test your Angular skills like never before.

One question to think about:

Have you considered SSR (server-side rendering) to boost performance? Even just using SSG can be a massive win performance-wise (the application is pre-rendered at build time)

Special Angular team event and more performance tips

For the second consecutive week, I want to experiment with a slightly different newsletter format inspired by James Clear’s 3-2-1 weekly newsletter. I aim to give you three short articles about Angular, two quick Angular ecosystem updates, and one question to make you think differently about the code you work with every day.

Three short articles to revisit:

Read this short challenge on Angular template syntax and then look at the solution and explanations here, here, and here.

Two updates to know about:

  • The Angular team is hosting a special event on YouTube today at 11 a.m. US/Pacific. If you miss the live event, a recording will be available shortly after.
  • A new feature called linkedSignal is in the works. So far, it seems similar to a computed signal that is also writable and only depends on one source signal.

One question to think about:

Do you know when to use the OnPush change detection strategy and how to differentiate container components from presentation components?

Let me know what you think about this different newsletter format. As always, it remains short and to the point. Also, if you have announcements you’d like to share in the newsletter, let me know.

Updates, debugging, and performance

This week, I want to experiment with a slightly different newsletter format inspired by James Clear’s 3-2-1 weekly newsletter. My goal is to give you three quick updates about the Angular ecosystem, two short topics to revisit, and one question to make you think differently about the code you work with daily.

Three updates to know about:

Two short articles to revisit:

How to use the Angular Devtools browser extension and the ng namespace functions for debugging.

One question to think about:

Do you know the size of your build output and regularly check or update your build budgets?

Let me know what you think about this different newsletter format. As always, it remains short and to the point.

Structural directives shorthand syntax

Have you ever wondered what’s behind the following syntax?

Whenever I teach Angular, people end up asking me: “Why is there a * before ngIf and ngFor? If I don’t use the *, the IDE seems to be OK with it.”

Well, yes and no. If you wanted to remove the *, then you would have to write:

In other words, *ngIf is a shorthand syntax for <ng-template [ngIf]>. It’s designed to make our template syntax more manageable and easier to read.

This is especially true if you use local variables from exported directive values. In those scenarios, the “long” syntax is barely readable with the let- declarations:

Note that this syntax trick applies to all directives if you prefix them with *. Here is an example where I created my own structural directive to select tab templates.