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.