What’s new with Signals in Angular 19?

Alain Chautard

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!

Alain Chautard

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

Alain Chautard

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!

Alain Chautard

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

Alain Chautard

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

Alain Chautard

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

Alain Chautard

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.

An Angular Upgrade Service?

Alain Chautard

Earlier this month, I polled people on LinkedIn to know which version of Angular they’re currently using at work. Here are the results:

First, I was pleasantly surprised that most of them (58%) are fully up-to-date or just one major version behind. What’s more worrying is that 24% of them use a non-supported version. So I asked why people use older versions of the framework (you can contribute here with your comments if you want), and of course, I knew more or less what the answers would be: Time – Budget – Dependencies.

This made me think about the following: What if there was an Angular Upgrade Service? A hands-on service you could subscribe to that would keep your projects up-to-date. Do you think that would be of interest?

I’m always looking for gaps to fill in the front-end development space. This is why I created the Angular certification program, the React certification program, and just helped launch a Javascript certification program!)

In any case, if you think you could use an Angular Upgrade Service, please let me know (respond to that email or reach out on LinkedIn – always happy to connect!), and I might beta-test that idea with you in the next quarter.

Syntax tricks for Angular HTML attribute bindings

Alain Chautard

What’s great about Angular is that the framework provides many different features out of the box. Some are well documented and widely known, while others are more obscure and less commonly used, though very useful.

For instance, there’s a ngClass directive to dynamically set classes to an element based on conditions:

In the above example, the button will have an active-btn CSS class if isActive is true, and a disabled-btn CSS class if isDisabled is true. That’s what the directive does.

But the thing is… We don’t need a directive to do that. I never use ngClass.

Instead, I do this:

It works the same way, and I’d argue that the syntax is slightly easier to understand. No directive needed.

On a different note, if you’ve ever tried to set the values of non-HTML attributes to an element, such as data-test for unit or end-to-end testing, you would find out that this syntax doesn’t work: [data-test]="value"

For these “unknown” HTML attributes, we need to use the following syntax: [attr.data-test]="value"

And then all is fine.

How to use Jest for Angular Unit Tests?

Alain Chautard

Karma is deprecated, and the Angular team is working on official support for Jest and Web Test Runner. Today, I want to highlight how to set up your Angular project for Jest since it’s prevalent in the Javascript ecosystem (React, etc.). It’s super fast and 100% browserless, making running tests on a continuous integration server easy.

Also, the syntax is essentially the same as Jasmine/Karma, so you won’t have to change your tests much unless you do extensive mocking in Jasmine.

Here are the steps I’ve used on over 28 repositories so far, with great success:

  1. Uninstall Jasmine, Karma, and all associated types
    npm uninstall karma karma-chrome-launcher karma-coverage karma-jasmine karma-jasmine-html-reporter @types/jasmine jasmine-core

  2. Install Jest, its types, and presets for Angular
    npm i --save-dev jest @types/jest jest-preset-angular

  3. Create a setup-jest.ts file in your project’s root folder
    And add that single line of code in it:
    import 'jest-preset-angular/setup-jest';

  4. Create a jest.config.ts file in your project’s root folder with the following command
    npx jest — init

    Then ensure you have the following config options set in that file:
    preset: 'jest-preset-angular',
    setupFilesAfterEnv: ['./setup-jest.ts']

  5. Update your tsconfig.spec.json file

    Your compilerOptions should look like this:
    "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": [ "jest" ],
    "esModuleInterop": true,
    "emitDecoratorMetadata": true
    },

  6. Last step: Update package.json
    In the scripts section, replace the test entry with:
    "test": "jest",

And… that’s it! You can now launch npm run test to run your tests with Jest. Sure, a schematic would be better, but those steps take only 2-3 minutes to implement for now.