In v19, Angular will introduce a new API for loading resources. This would allow us to fetch data from an API, know about the status of the request, and update the data locally when needed.

Intro

The resource API is straightforward in its core. Let’s see the most simple example of how to use it.

import { resource } from "@angular/core";

@Component({})
export class MyComponent {
  todoResource = resource({
    loader: () => {
      return Promise.resolve({ id: 1, title: "Hello World", completed: false });
    },
  });

  constructor() {
    effect(() => {
        console.log("Value: ", this.todoResource.value());
        console.log("Status: ", this.todoResource.status());
        console.log("Error: ", this.todoResource.error());
    })
  }
}

First, we can notice that the resource API uses Promises by default for the loader parameter. The other one is that the resource API will return an WritableResource object, which helps us to update the data locally when needed.

We can read the current value of the resource by using the value signal, the status of the resource by using the status signal, and the error of the resource by using the error signal.

The code above will print the following:

Value: undefined
Status: 'loading'
Error: undefined

Value: { id: 1, title: "Hello World", completed: false }
Status: 'resolved'
Error: undefined

Updating the data locally

Let’s see how we can update the data locally.

import { resource } from "@angular/core";

@Component({
    template: `
        <button (click)="updateTodo()">Update</button>
    `
})
export class MyComponent {
  todoResource = resource({
    loader: () => {
      return Promise.resolve({ id: 1, title: "Hello World", completed: false });
    },
  });

  updateTodo() {
    this.todoResource.value.update((value) => {
      if (!value) return undefined;
      
      return { ...value, title: "updated" };
    });
  }
}

We can update the data locally by using the update method of the value signal.

This will print the following:

Value: { id: 1, title: "updated", completed: false }
Status: 'local'
Error: undefined

The ‘local’ status means that the data was updated locally.

Loading the data

Let’s make a proper request to the server. Let’s load some todos from the JSONPlaceholder API.

interface Todo {
  id: number;
  title: string;
  completed: boolean;
}

@Component()
export class MyComponent {
  todosResource = resource({
    loader: () => {
      return fetch(`https://jsonplaceholder.typicode.com/todos?_limit=10`)
        .then((res) => res.json() as Promise<Todo[]>);
    },
  });
}

This todosResource will start to make the request to the server immediately after it has been created.

Of course, the todosResource will not have a value yet, because the request is still in progress.

The code above will print the following:

Value: undefined
Status: 'loading'
Error: undefined

Value: [{ id: 1, title: "Hello World", completed: false }, { id: 2, title: "Hello World", completed: false }, ...]
Status: 'resolved'
Error: undefined

Refreshing the data

Let’s say we want to refresh the data when the user clicks on a button.

import { resource } from "@angular/core";

@Component()
export class MyComponent {
  todosResource = resource({
    loader: () => {
      return fetch(`https://jsonplaceholder.typicode.com/todos?_limit=10`)
        .then((res) => res.json() as Promise<Todo[]>);
    },
  });

  refresh() {
    this.todosResource.refresh();
  }
}

The refresh function will run the loader function again. If you call the refresh function multiple times, the loader function will be called only once until the previous request is finished (like exhaustMap behavior in RxJS).

Loading specific data based on other signals

Let’s say we want to load the todos based on a todoId signal.

import { resource } from "@angular/core";

@Component()
export class MyComponent {
  todoId = signal(1);

  todoResource = resource({
    loader: () => {
      return fetch(
        `https://jsonplaceholder.typicode.com/todos/${this.todoId()}`
      ).then((res) => res.json() as Promise<Todo>);
    },
  });
}

This will work fine, but one thing to notice is that loader is untracked and that means, that if the todoId signal changes, the load won't be called again. Let's make it more reactive!

Separate the request and the loader

We want our resource to refresh the data (call the loader again) every time the todoId changes. For this, we can use the request field of the resource. We can pass a signal to it, and it will be tracked.

todoResource = resource({
    request: this.todoId, 
    loader: ({ request: todoId }) => {  
        return fetch( 
          `https://jsonplaceholder.typicode.com/todos/${todoId}`,
        ).then((res) => res.json() as Promise<Todo>);
    },
});

Now, when the todoId signal changes, the resource API will automatically fetch the new data.

What if we have previous unfinished requests? Let’s say we want to cancel the previous request when the todoId changes. Well, we can do that by using the abortSignal that is passed to the loader function.

todoResource = resource({
    request: this.todoId, 
    loader: ({ request: todoId, abortSignal }) => {  
        return fetch( 
          `https://jsonplaceholder.typicode.com/todos/${todoId}`, 
          { signal: abortSignal } 
        ).then((res) => res.json() as Promise<Todo>);
    },
});

This will cancel the previous request when the todoId changes and if the previous request is still in progress.

We can also have multiple request dependencies, for example:

limit = signal(10);
query = signal('');

todosResource = resource({
    request: () => ({ limit: this.limit(), query: this.query() }),
    loader: ({ request, abortSignal }) => {   
        const { limit, query } = request as { limit: number; query: string };
        return fetch(
          `https://jsonplaceholder.typicode.com/todos?_limit=${limit}&query=${query}`, 
          { signal: abortSignal } 
        ).then((res) => res.json() as Promise<Todo[]>);
    },
});

Now, the todosResource will make the request based on the limit and query signals, and the loader function will be able to use those signals to make the request, and anytime the limit or query signal changes, the loader function will be called again.

What happens when we have a request in progress and update data locally?

If that’s the case, the resource API will automatically update the data locally, but cancel the ongoing request.

How to postpone making the API request?

There are cases, when we don’t want to make the API request immediately, but do it only on some conditions only. A feature of the loader is that it won’t make the API request if the request returns undefined. We can use that as the example below:

query = signal('');
pageIsActive = signal(true);

todosResource = resource({
    request: () => pageIsActive() ? this.query(): undefined,
    loader: ({ request: query, abortSignal }) => {   
        return fetch(
          `https://jsonplaceholder.typicode.com/todos?query=${query}`, 
          { signal: abortSignal } 
        ).then((res) => res.json() as Promise<Todo[]>);
    },
});

This enables us to only make the API request when the pageIsActive() signal is true . This may be the case when you use the resource function in a service.

Create more reusable resources

By separating reactive values from the loader function, we can move the logic of the loader function to a separate function, and store it where we want.

Before:

todoResource = resource({
    request: this.todoId,
    loader: ({ request: todoId, abortSignal }) => {  
        return fetch(
          `https://jsonplaceholder.typicode.com/todos/${todoId}`, 
          { signal: abortSignal } 
        ).then((res) => res.json() as Promise<Todo>);
    },
});

After:

import { ResourceLoaderParams } from "@angular/core";

function todoLoader({ request: todoId, abortSignal }: ResourceLoaderParams<number>): Promise<Todo> {
    return fetch(
      `https://jsonplaceholder.typicode.com/todos/${todoId}`, 
      { signal: abortSignal } 
    ).then((res) => res.json() as Promise<Todo>);
}

todoResource = resource({ request: this.todoId, loader: todoLoader });

The todoLoader can be moved anywhere, and also can be reused by other resources. The ResourceLoaderParams type is a type that contains all the information that is needed to make the request, and the request parameter is the one that is passed to the loader function.

RxResource -> The observable-based resource API

Angular has always been about using Observables when it comes to data loading. This means, that we can use Observables to derive the data loading instead of using signals & promises.

To make this possible, we can use the rxResource function.

import { rxResource } from "@angular/core/rxjs-interop";

@Component()
export class MyComponent {
  limit = signal(10);

  todosResource = rxResource({
    request: this.limit,
    loader: (limit) => {
      return this.http.get<Todo[]>(
        `https://jsonplaceholder.typicode.com/todos?_limit=${limit}`
      );
    },
  });
}

This will make the request based on the limit signal, and the loader function will be able to use the limit value to make the request, and same as signals, anytime the limit signal changes, the loader function will be called again and cancel the previous request (same as switchMap behavior in RxJs)

And same as we can change the local state with the signals, we can also change the local state with the observable implementation in the rxResource function.

Summary

We have 2 new primitives [resource, rxResource] that will help us make our life easier when dealing with data loading in Angular. These primitives have been requested for so long now, and will land in v19 as developer previews.

PR link: https://github.com/angular/angular/pull/58255

📹 Detailed explanation from Josh Morony

📢 Announcements

NgGlühwein 2024

For the first time ever the Push-Based team will host a workshop day on the day before the NgGlühwein conference. There will be two workshops held simultaneously:

• Architecting Angular Apps for High Performance
• Nx for Scalable Architecture

Join conference for free (in-person & online) 👇:
https://www.meetup.com/angular-vienna/events/304004182

Thanks for reading!

If this article was interesting and useful to you, and you want to learn more about Angular, support me by buying me a coffee ☕️ or follow me on X (formerly Twitter) @Enea_Jahollari where I tweet and blog a lot about Angular latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more. 💎

When working with Angular, we often find ourselves in situations where we need to pass data from a parent component to a child component. This is usually done using @Input properties. However, as the application grows, we might find ourselves in a situation where we have to pass the same data through multiple levels of components. This is known as prop drilling and can make our code harder to maintain and understand.

In this article we will see how we can use the new Signal Inputs and Dependency Injection to provide inputs to components without having to pass them through multiple levels of components.

Before Signal Inputs

Let’s start by looking at an example of how we would pass data from a parent component to a child component using @Input properties.

@Component({
  template: `<app-child [data]="data" />`,
})
export class ParentComponent {
  @Input() data: string;
}

@Component({
  template: `<app-inner-child [data]="data" />`,
})
export class ChildComponent {
  @Input() data: string;
}

@Component({
  template: `{{ data }}`,
})
export class InnerChildComponent {
  @Input() data: string;
}

In this example, we have a ParentComponent that passes data to a ChildComponent, which in turn passes the data to an InnerChildComponent. This is a simple example.

In order to solve this problem, we have used what we call services.

So, it will look something like this:

@Injectable()
export class DataService {
  data: string;

  setData(data: string) {
    this.data = data;
  }
}

@Component({
  template: `<app-child />`,
  providers: [DataService],
})
export class ParentComponent {
  dataService = inject(DataService);

  // using ngOnChanges to update the data in the service
  @Input() data: string;

  ngOnChanges(changes: SimpleChanges) {
    if (changes.data) {
      this.dataService.setData(this.data);
    }
  }

  // or using a setter
  @Input() set data(value: string) {
    this.dataService.setData(value);
  }
}

@Component({
  template: `<app-inner-child />`,
})
export class ChildComponent {
  // no need to inject the service here as we don't need it here
}

@Component({
  template: `{{ dataService.data }}`,
})
export class InnerChildComponent {
  dataService = inject(DataService);
}

This works great, until we need to convert our components to use OnPush change detection strategy. Because we are not using @Inputs(), Angular cannot check if the data has changed and will not update the view (if the event didn't come from the child component itself).

To solve this we have relied on rxjs BehaviorSubject. Why? Because we can subscribe to it and get the latest value whenever it changes and subscribe to changes using async pipe which will trigger markForCheck under the hood that lets Angular know that this component's data has changed.

@Injectable()
export class DataService {
  private readonly data = new BehaviorSubject<string>("");
  readonly data$ = this.data.asObservable();

  setData(data: string) {
    this.data.next(data);
  }
}

@Component({
  template: `{{ dataService.data$ | async }}`,
})
export class InnerChildComponent {
  dataService = inject(DataService);
}

One other way to solve this would be to inject the parent component itself into the child component and access the data directly.

@Component({
  template: `{{ parentComponent.data }}`,
})
export class InnerChildComponent {
  parentComponent = inject(ParentComponent);
}

This is great until you start to hit circular dependency issues.

Signal Inputs approach

In order to benefit from Angular enhanced change detection, more here:

A change detection, zone.js, zoneless, local change detection, and signals story 📚

we can use the new Signal Inputs feature.

@Component({
  template: `<app-child />`,
})
export class ParentComponent {
  data = input<string>();
}

@Component({
  template: `{{ parentComponent.data() }}`,
})
export class InnerChildComponent {
  parentComponent = inject(ParentComponent);
}

This is the same as the previous example, but we are using signals instead of normal properties. This will still be affected by circular dependency issues.

What we can do is to have an InjectionToken which can be used to provide this component input in the DI tree.

export const DATA = new InjectionToken<Signal<string>>("DATA");

@Component({
  template: `<app-child />`,
  providers: [
    {
      provide: DATA,
      useFactory: () => inject(ParentComponent).data,
    },
  ],
})
export class ParentComponent {
  data = input<string>();
}

@Component({
  template: `{{ data() }}`,
})
export class InnerChildComponent {
  data = inject(DATA);
}

Let's break down the code above:

We have created an InjectionToken called DATA that will hold the signal for the data. Note that it's a Signal<string> and not just string because we want to be able to read it only where we need it.

We have provided the DATA token in the ParentComponent's providers array. We are using the useFactory property because it allows us to inject the ParentComponent and get the data signal from it.

We are not calling the data signal directly in the useFactory function because we want to be able to read it only where we need it and not have it in the DI tree.

We have injected the DATA token in the InnerChildComponent and assigned it to the data property. And now we can read the data signal in the template.

This way we can provide inputs to components without having to pass them through multiple levels of components and without having to rely on services or BehaviorSubjects.

Also, this is 100% compatible with OnPush change detection strategy, because we are using signals, which are part of the new Angular change detection system and will trigger change detection when the signal changes.

It is also compatible with Zoneless Angular, because signals are part of the new Angular change detection system and do not rely on Zone.js.

This is a great way to remove prop drilling from your Angular applications and make your code more maintainable and easier to understand.

One more thing

We can also read the token in the services provided in the same component or child components.

@Injectable()
export class DataService {
  data = inject(DATA); // data is a signal here
  
  constructor() {
    effect(() => {
      console.log(this.data()); // use data() to make API calls maybe?
    });
  }
}

@Component({
  template: `<app-child />`,
  providers: [
    {
      provide: DATA,
      useFactory: () => inject(ParentComponent).data,
    },
    DataService, // <- provide the service here
  ],
})
export class ParentComponent {
  data = input<string>();
}

Use one token for multiple signal inputs or other signals

If you have multiple inputs that you want to provide to a component, you can use a single token and provide an object with multiple signals.

export const INPUTS = new InjectionToken<{
  data: Signal<string>;
  options: Signal<Record<string, string>>;
}>("INPUTS");

@Component({
  template: `<app-child />`,
  providers: [
    {
      provide: INPUTS,
      useFactory: () => {
        const cmp = inject(ParentComponent);
        return {
          data: cmp.data, 
          options: cmp.options,
          count: cmp.someNormalSignal,
        };
      },
    },
  ],
})
export class ParentComponent {
  data = input<string>();
  options = input<Record<string, string>>();
  count = signal<number>();
}

Hope this helps you to remove prop drilling from your Angular applications and make your code more maintainable and easier to understand. 🚀

Thanks for reading!

If this article was interesting and useful to you, and you want to learn more about Angular, support me by buying me a coffee ☕️ or follow me on X (formerly Twitter) @Enea_Jahollari where I tweet and blog a lot about Angular latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more. 💎

Providing inputs in DI 🎁 was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Give me let Angular

If you have worked with Angular long enough, probably at some point you would have wanted to declare a variable inside the template. This is a common use case when you want to store a value that you will use later in the template.

The most common way to do this is by using a directive like ngIf and assign the value to a variable using the as keyword. For example:

<div *ngIf="user$ | async as user">
  <h1>{{ user.name }}</h1>
</div>

<!-- or using the new control flow -->
@if (user$ | async; as user) {
  <h1>{{ user.name }}</h1>
}

What if you’re working with numbers?

<div>
    @if (points$ | async; as points) {
        <h1>You have: {{ points }} points!</h1>
    }
</div>

What would you see in the template if points is 0? You would see NOTHING! because 0 is a falsy value and when used inside the if block, it will not render the content.

This is where the new @let block comes into play. The @let block will allow you to declare a variable inside the template and use it later in the template. Let's see how it works.

<div>
    @let points = (points$ | async) ?? 0;  
    <h1>You have: {{ points }} points!</h1>
</div>

This will render the content even if points is 0. This is because the let block is not checking for falsy values, it's just declaring a variable at that point in the template.

Also, one of the most common use cases for the @let block would be to store a variable that allows us to store aliases for complex expressions. For example:

@let someField = someService.someSignal().someProperty.someOtherProperty;
<div>{{ someField }}</div>

How to use @let in Angular

You can use the new @let in multiple ways:

• With async pipes:

<div>
    @let user = (user$ | async) ?? { name: 'Guest' };  
    <h1>{{ user.name }}</h1>
</div>

• With control flow directives:

<div>
    @let user = user$ | async;  
    @if (user) {
        <h1>{{ user.name }}</h1>
    }
</div>

• Inside @for to refactor code duplications:

<mat-selection-list>
    @for (item of items(); track item.id) {
        @let isSelected = item.id === selectedId();
        <mat-list-option [selected]="isSelected" [class.selected]="isSelected">
            {{ item.text }} 
            @if (isSelected) {
                <span>(selected)</span>
            }
        </mat-list-option>
    }
</mat-selection-list>

• With ternary operators:

<div>
    @for (game of games; track game.id) {
        @let points = calcPoints(game.points > 0 ? game.points : 0);  
        <h1>You have: {{ points }} points!</h1>
    }
</div>

• With basic math operators:

<div>  
    @for (game of games; track game.id) {
        @let total = previousTotal + game.points;  
        <h1>Total points: {{ total }}</h1>
    }
</div>

• With signals:

<div>  
    @let username = user()?.name ?? 'Guest';
    <h1>Welcome, {{ username }}</h1>
</div>

• Multiple declarations inline or in multiple lines:

<div>  
    @let total = count + previousCount, average = calcAverage(count), (can I use `total` here?)
    
    @let total = count + previousCount, 
         average = calcAverage(count)
    <h1>{{total}}</h1>
</div>

Good to know

Let declaration will work almost the same as let declarations in JavaScript.

• Scoping will work the same as let in javascript.
• Type inference just works!
• Let declarations will have precedence to a local let declaration over a component property.
• A let declaration cannot be referenced before it is defined, with the exception when it’s used inside an event handler.

This feature closes an issue that has been open since Mar 2017

Template Local Variables · Issue #15280 · angular/angular

In the PR you can see some alternatives that were considered before the @let block was introduced.

• @const instead of @let
• entirely new keyword
• @var instead of @let
• block-like syntax

More info about the PR is here:

Start implementation of @let syntax by crisbeto · Pull Request #55848 · angular/angular

That’s it! This is how you can use the new @let block in Angular templates. This feature probably will be available in Angular v18.1, which is expected to be released in the upcoming months.

Let me know of any other use cases you can think of for the @let block in Angular templates. 🚀

Thanks for reading!

If this article was interesting and useful to you, and you want to learn more about Angular, support me by buying me a coffee ☕️ or follow me on X (formerly Twitter) @Enea_Jahollari where I tweet and blog a lot about Angular latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more. 💎

Template local variables with @let in Angular was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you have read my previous articles about Angular change detection, you know what manual change detection calls are and on this article, I will show you how they work and how I’m removing them from my Angular applications.

Let’s start with a simple example, where I have a service that fetches the user’s name and I want to display it in a component.

@Injectable({ providedIn: 'root' })
export class UserService {
  #http = inject(HttpClient);  getUser() {
    return this.#http.get<string>('/api/user');
  }
}

@Component({
    template: `<div>{{ username }}</div>`,
})
export class UserComponent {
  #userService = inject(UserService);
  username: string = '';

  ngOnInit() {
    this.#userService.getUser().pipe(take(1)).subscribe(user => {
      this.username = user.name;
    });
  }
}

If you run this code in an Angular application, it will just work! That’s thanks to zone.js. Why is that? Zone.js is intercepting XHR requests that are made and is telling Angular to run change detection that some data has changed. This is why you see the username in the view.

More about it here: A change detection, zone.js, zoneless, local cd, and signals story 📚

But what if you want to use ChangeDetectionStrategy.OnPush for better performance in your component?

@Component({
    template: `<div>{{ username }}</div>`,
    changeDetection: ChangeDetectionStrategy.OnPush,
})
export class UserComponent { /*...*/ }

Now that we have OnPush enabled, our view is not going to be updated when the name changes, because nothing is telling Angular that this component's data has changed. This is where manual change detection calls come into play.

To fix this, we can call ChangeDetectorRef's markForCheck method to tell Angular to mark this component as dirty and to refresh the bindings/interpolations in the next change detection.

export class UserComponent {
  #cdr = inject(ChangeDetectorRef);

  ngOnInit() {
    this.#userService.getUser().pipe(take(1)).subscribe(user => {
      this.username = user.name;
      this.#cdr.markForCheck();
    });
  }
}

This is great, and it works fine! Then another feature comes in, and you need to update the user’s name and add a button to change it, and call the markForCheck method again.

export class UserComponent {
  username?: string;
  
  handleNameChange(newName: string) {
    this.#userService.changeName(newName).pipe(take(1)).subscribe(name => {
      this.username = name;
      this.#cdr.markForCheck(); 
    });
  }
}

As you can see, this can get out of hand quickly, and you can forget to call markForCheck in some places, which can lead to bugs in your application.

In order to solve this we would use rxjs and observables, and use the async pipe in the template to let Angular know that this component's data has changed as it calls markForCheck under the hood.

Read more about it here: Async pipe is not pure 🤯

Our component would look like this:

@Component({
    template: `<div>{{ username$ | async }}</div>`,
    changeDetection: ChangeDetectionStrategy.OnPush,
    imports: [AsyncPipe]
})
export class UserComponent {
  #userService = inject(UserService);
  #cdr = inject(ChangeDetectorRef);
  
  username$ = new BehaviorSubject<string>(''); 

  ngOnInit() {
    this.#userService.getUser().pipe(take(1)).subscribe(user => {
      this.username$.next(user.name);
    });
  }

  handleNameChange(newName: string) {
    this.#userService.changeName(newName).pipe(take(1)).subscribe(name => {
      this.username$.next(name);
    });
  }
}

This is perfectly valid code, now we won’t need to call markForCheck anymore, and we can be sure that the view will be updated when the data changes.

Having to create BehaviorSubjects and using the async pipe in the template can be a bit cumbersome, and this is where Angular signals come into play.

Signals are a new way to handle state in Angular, and they are very powerful and greatly simplify the way we write Angular applications and in the same time improve the performance of our applications, because Angular thinks in signals now.

Step by step guide to remove manual change detection

• [Optional] Use ESLint to find all manual CD calls

If you’re using ESLint there is a package which you can install that will show you all the manual CD calls in your application.

RxAngular publishes an ESLint plugin with a set of ESLint rules for building reactive, performant and Zone-less Angular applications.

You can find it here: RxAngular ESLint Plugin

npm install --save-dev @rx-angular/eslint-plugin

Enable the rule:

{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@rx-angular"],
  "rules": {
    "@rx-angular/no-explicit-change-detection-apis": "error",
  }
}

• Check why the manual CD call was needed In our case, we are using OnPush and we need to tell Angular when the data has changed.

username: string = '';

ngOnInit() {
    this.#userService.getUser().pipe(take(1)).subscribe(user => {
        this.username = user.name;
        this.#cdr.markForCheck();
    });
}

Let’s replace the username field with a signal.

- username: string = '';
+ username = signal(''); // Will be typed as WritableSignal<string>

Now we will see that it will throw an error when we try to set a new value to the field inside the subscription.

ngOnInit() {
    this.#userService.getUser().pipe(take(1)).subscribe(user => {
        // ❌ Type 'string' is not assignable to type 'WritableSignal<string>'.
        this.username = user.name;
        this.#cdr.markForCheck();
    });
}

But, if your application is not using Typescript strict mode, you won’t see this error. In this case, you should also use the readonly keyword to make sure that the value is never set directly.

- username = signal('');
+ readonly username = signal('');

Now Typescript will throw an error if you try to set the value directly.

this.#userService.getUser().pipe(take(1)).subscribe(user => {
    // ❌ Cannot assign to 'username' because it is a read-only property.
    // this.username = user.name;
    // ✅ To set the value you should use the set method 
    this.username.set(user.name); 
});

Now, don’t forget to call this signal in the template in order to show the value.

- <div>{{ username }}</div>
+ <div>{{ username() }}</div>

And that’s it! You have removed the manual change detection call from your Angular application.

Why does this work? Well, signals will mark the template as dirty and as needed to be checked by Angular when they change, but also, in a zoneless world, they also trigger a Change Detection cycle which will update the view with the new value.

Read more about it here: A new era for Angular — Zoneless Change Detection

I’m also looking to create an eslint rule that does all of this automatically for you, so you don’t have to do it manually. If you’re interested in this, let me know in the comments below.

Thanks for reading!

If this article was interesting and useful to you, and you want to learn more about Angular, support me by buying me a coffee ☕️ or follow me on X (formerly Twitter) @Enea_Jahollari where I tweet and blog a lot about Angular latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more. 💎

Removing manual change detection calls from my Angular app ⚡️ was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lately, Angular introduced signals, that are wonderfully powerful and greatly simplify the way we write Angular applications.

When working with signals in Angular, we know that Angular will make sure to always update the view when a signal is changed.

@Component({
  template: `
    <div>{{ count() }}</div>
    <button (click)="increment()">Increment</button>
  `
})
export class AppComponent {
  count = signal(0);

  increment() {
    this.count.update(x => x + 1);
  }
}

One other thing Angular has introduced is the afterRender lifecycle hook. This hook is called after Angular has rendered the view, which is a great place to do some work that should be done after the view has been updated.

@Component()
export class AppComponent {
  count = signal(0);
  
  constructor() {
    afterRender(() => {
      console.log('View has been updated');
    });
  }
}

If for some reason you need to update the view in the afterRender hook, and to do that you're updating a signal (which may have been called in the component's template), please make sure to not update the signal in an non-definitive way.

@Component({
  template: `
    <div>{{ count() }}</div>
  `
})
export class AppComponent {
  count = signal(0);
  
  constructor() {
    afterRender(() => {
      // This will cause an infinite change detection loop
      this.count.update(x => x + 1);
    });
  }
}

If you update a signal in the afterRender hook, make sure to update it in a definitive way. This means that the signal should be updated in a way that it will not change the value of the signal when the view is updated.

@Component({
  template: `
    <div>{{ count() }}</div>
  `
})
export class AppComponent {
  count = signal(0);
  
  constructor() {
    afterRender(() => {
      // This will not cause an infinite change detection loop
      this.count.set(/* new value */); 
    });
  }
}

By following this simple rule, you can protect your Angular app from infinite change detection loops.

Protect your Angular app from infinite change detection loops ♾️ was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lazy loading components in Angular has not been an easy task for a long time. We had to go over `ngComponentOutlet` and dynamic imports and also handle different kind of events to load the desired component.

Example in the Movies app

In the movies app we have an example in the `app-shell.component.ts` where we lazy load an account menu component when the user clicks on the account button.

<div class="account-menu-dropdown">
  <button 
    type="button" 
    class="profile-button" 
    (mouseenter)="ui.loadAccountMenu()">
      <div class="focus-overlay"></div>
      <fast-svg name="account" />
  </button>
  <div class="profile-menu-content">
    <ng-container 
        *rxLet="accountMenuComponent$; suspense: loading" 
        [lazy]="accountMenuComponent$" />
    <ng-template #loading> Loading...</ng-template>
  </div>
</div>

type Actions = {
  ...
  loadAccountMenu: void;
};

export class AppShellComponent {
  readonly ui = rxActions<{ loadAccountMenu: void }>();

  accountMenuComponent$ = this.ui.loadAccountMenu$.pipe(
    switchMap(() =>
      import('./account-menu/account-menu.component').then((x) => x.default)
    ),
    shareReplay(1)
  );
}

So, we create an `ui` actions object and we have a `loadAccountMenu` action that we call when the user clicks on the account button.

We have a `accountMenuComponent$` observable that we use to lazy load the `AccountMenuComponent` when the user clicks on the account button.

The observable is then used in the `*rxLet` directive to render the `AccountMenuComponent` when it’s loaded.

Migrating to defer block

Defer block is a new feature in Angular that allows us to defer the rendering of a component until it’s loaded.

We can use the `defer` block to achieve the same result as the previous example.

<div class="account-menu-dropdown">
  <button #accountButton type="button" class="profile-button">
    <div class="focus-overlay"></div>
    <fast-svg name="account" />
  </button>
  <div class="profile-menu-content">
    @defer (on hover(accountButton)) {
        <app-account-menu />
    } @placeholder {
        Loading...
    }
  </div>
</div>

That’s it. We don’t need to use any observables or actions, or register any listeners to load the `AccountMenuComponent`. We can safely remove the observable, the *rxLet directive and the actions object.

The `on hover()` will register an event listener on the `accountButton` and when the user hovers over the button, the `AccountMenuComponent` will be loaded and rendered.

More info in the defer block docs.

Thanks for reading!

If this article was interesting and useful to you, and you want to learn more about Angular, support me by buying me a coffee ☕️ or follow me on X (formerly Twitter) @Enea_Jahollari where I tweet and blog a lot about Angular latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more. 💎

Migrating from Custom Lazy Loading components to defer block was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building single-page applications with Angular often involves working with the Angular Router.

When working with the router there are a few common patterns that we often find ourselves repeating.

For example, we often need to grab the current route params or query params and use them in our components.

@Component({
  template: `
    <h1>Product Details</h1>
    <p>{{ productName }}</p>
  `
})
export class ProductDetails {
  private route = inject(ActivatedRoute);
  private productsService = inject(ProductsService);

  productName: string = '';

  ngOnInit() {
    const prodcutId = this.route.snapshot.params['id'];

    this.productsService.getProduct(prodcutId)
    .pipe(take(1))
    .subscribe(product => {
      this.productName = product.name;
    });
  }
}

In the above example, we are using the `ActivatedRoute` to grab the current route params and then using the `ProductsService` to fetch the product details.

The issue with the above code is that when the route params change, the component will not update the `productName` value. Let’s fix that.

Let’s make this more declarative and reactive using observables.

Using Observables to react to route changes

Just like we used the snapshot to grab the route params, we can use the `params` observable to listen to route params changes.

@Component({
  template: `
    <h1>Product Details</h1>
    <p>{{ productName$ | async }}</p>
  `
})
export class ProductDetails {
  private route = inject(ActivatedRoute);
  private productsService = inject(ProductsService);

  // Store the productId observable
  productId$ = this.route.params.pipe(map(params => params['id']));

  productName$ = this.productId$.pipe(
    // Fetch the product details when the productId changes
    // and cancel the previous request
    switchMap(id => this.productsService.getProduct(id)),
    map(product => product.name)
  );
}

Here we have a declarative and reactive way to fetch the product details when the route params change using observables, that will also cancel the previous request when the route params change (this is useful when the user is navigating quickly between routes).

We are using the `async` pipe to subscribe to the `productName$` observable and display the product name in the template.

Refactoring to Signals

We can take this a step further and refactor the observables into signals. Let’s use the `toSignal` function to convert the observables into signals.

@Component({
  template: `
    <h1>Product Details</h1>
    <p>{{ productName() }}</p> <!-- No need for async pipe -->
  `
})
export class ProductDetails {
  private route = inject(ActivatedRoute);
  private productsService = inject(ProductsService);

  productId$ = this.route.params.pipe(map(params => params['id']));

  productName$ = this.productId$.pipe(
    switchMap(id => this.productsService.getProduct(id)),
    map(product => product.name)
  );

  // This will convert the productName$ observable into a signal 
  // and will be updated when the productName$ observable emits a new value
  productName = toSignal(this.productName$, { initialValue: '' });
}

Now we have a `productName` signal that will be updated when the `productName$` observable emits a new value. This is great! We can now use the `productName` signal in our template without the need for the `async` pipe.

Can we do better? To, write less code maybe?

Creating a reusable router signals API

We can create a reusable router signals API that will allow us to easily grab the current route params and query params and use them in a declarative way using signals.

We want to be able to inject params that should return us all the route params as a signal, and if we pass a key, it should return us the value of that key as a signal.

Something like this:

export class ProductDetails {
  params = injectParams(); // Signal<Params>
  productId = injectParams('id'); // Signal<string | null>

  private productsService = inject(ProductsService);

  // usage with computedAsync function
  productName = computedAsync(() => 
    this.productsService.getProduct(this.productId()).pipe(map(p => p.name))
  );
}

More info about `computedAsync` can be found in the docs.

I wrote more about it here:

Building ComputedAsync for Signals in Angular

Implementing the injectParams function

Because our function will inject the `ActivatedRoute` we need to make sure we are in an injection context. We can use the `assertInInjectionContext` function to do that.

export function injectParams(): Signal<Params> {
  assertInInjectionContext(injectParams);
  const route = inject(ActivatedRoute);
}

Now that we have access to the `ActivatedRoute` we can grab the route params and convert them into a signal using the `toSignal` function.

export function injectParams(): Signal<Params> {
  assertInInjectionContext(injectParams);
  const route = inject(ActivatedRoute);
+  return toSignal(route.params);
}

Params emit synchronously, so to enforce it, let’s use `toSignal` with `requireSync` option.

export function injectParams(): Signal<Params> {
  assertInInjectionContext(injectParams);
  const route = inject(ActivatedRoute);
+  return toSignal(route.params, { requireSync: true });
}

We can also add support for passing a key to the `injectParams` function. If a key is passed, we should return the value of that key as a signal.

export function injectParams<T>(
+  key?: string // Include the optional key parameter
): Signal<Params | string | null> {
  assertInInjectionContext(injectParams);
  const route = inject(ActivatedRoute);
  // Create a helper function to grab the value of the key
+  const getParam = (params: Params) => key ? params?.[key] ?? null : params;
  // We need to map the params observable to the value of the key
-  return toSignal(route.params, { requireSync: true });
+  return toSignal(route.params.pipe(map(getParam)), { requireSync: true });
}

We can extend the `injectParams` function to also support a transform function that will allow us to transform the params into a different value.

It will be used like this:

export class ProductDetails {
  // example of using a transform function
  allParamKeys = injectParams(params => Object.keys(params));
}

While we add the support for the transform function, we can also make the function generic to support the return type of the transform function.

export function injectParams<T>(
 keyOrTransform?: string | ((params: Params) => T),
): Signal<T | Params | string | null> {
  assertInInjectionContext(injectParams);
  const route = inject(ActivatedRoute);
 
  if (typeof keyOrTransform === 'function') {
    return toSignal(route.params.pipe(map(keyOrTransform)), { requireSync: true });
  }

  const getParam = (params: Params) =>
    keyOrTransform ? params?.[keyOrTransform] ?? null : params;

  return toSignal(route.params.pipe(map(getParam)), { requireSync: true });
}

As we can see, we have created a reusable router signals API that will allow us to easily grab the current route params and use them in a declarative way using signals.

We can do the same for the query params using the `queryParams` observable from the `ActivatedRoute`.

But, you don’t need to do that, because it’s already done for you in the `ngxtension` library.

`injectQueryParams` and `injectParams`

These two functions are already published by the `ngxtension` library

- injectParams

- injectQueryParams

They are fully tested and are already being used in multiple projects.

Using `withComponentInputBinding()` with signal inputs

In v17.1 Angular introduced signal inputs, and before that introduced the `withComponentInputBinding()` function which enables us to have inputs with the same name as our params or query params.

I wrote about that function here:

Bind Route Info to Component Inputs (New Router feature)

What’s the difference between these functions and signal inputs? Two things:

• Being explicit about where your data comes from

If you have an input called productId, do you expect it to come from a parent component or the route params?

export class ProductDetails {
  // where does this come from?
  productId = input<string>(); 

  // being explicit we are getting a route param
  productId = injectParams('id'); 

  private productsService = inject(ProductsService);

  // we can use computedAsync with both ways btw.
  productName = computedAsync(() => 
    this.productsService.getProduct(this.productId()).pipe(map(p => p.name))
  ); 
}

• What if you need all the params (or query params)

We cannot grab all the params and queryParams using inputs, so we still have to rely on injecting `ActivatedRoute` and listen to observable changes. And that’s something `injectParams` solves by default.

export class AllProducts {
  private productsService = inject(ProductsService);
  private productsFilters = injectParams(p => paramsToFilters(p));

  allProducts = computedAsync(() => 
    this.productsService.getProducts(this.productsFilters()))
  );
}

function paramsToFilters(params: Params): ProductsFilters {
  return ...;
}

That’s all folks! Hope you liked it!

Thanks for reading!

If this article was interesting and useful to you, and you want to learn more about Angular, support me by buying me a coffee ☕️ or follow me on X (formerly Twitter) @Enea_Jahollari where I tweet and blog a lot about Angular latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more. 💎

Creating reusable Router Signals APIs in Angular 🗺️ was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

A little bit of history

Handling async operations in Angular has always been the job of Observables. Observables are a great way to handle async operations. But with the introduction of Signals in Angular, everyone is trying to use Signals for everything, but Signals are not meant to handle async operations. Signals are meant to handle value and not events. So, how do we handle async operations using Signals? Let’s find out.

Motivation

I will use a simple example for an API call. Let’s say we have a component that calls an API and displays the data. We will use the `HttpClient` to make the API call. The `HttpClient` returns an `Observable` which we can subscribe to and get the data. Let’s see how we can do this using Signals.

export class UserComponent {
  private imagesService = inject(ImagesService);

  user = input.required<User>();

  favoriteImages = signal<string[]>([]);

  constructor() {
    effect(() => {
      this.imagesService.getImages(this.user().favoriteImages).subscribe(images => {
        this.favoriteImages.set(images);
      });
    });
  }
}

As you can see, I’m also using signal inputs to use the built-in reactivity.

But, we don’t handle the unsubscribe part. So, we need to do that manually. The effect function includes a callback function that is called every time the effect runs. We can use that to unsubscribe from the subscription.

This is how we can do it.

export class UserComponent {
  constructor() {
    // onCleanup is a callback function that is called everytime the effect runs
    effect((onCleanup) => { 
      const sub = this.imagesService.getImages(this.user().favoriteImages).subscribe(images => {
        this.favoriteImages.set(images);
      });
      onCleanup(() => sub.unsubscribe()) // unsubscribe from the subscription
    });
  }
}

To sum up, here’s what’s happening in the above code:

• We register an effect that will run whenever the `user` input changes.
• The effect runs at least once by default, so it will make that initial API call.
• The effect will run again whenever the `user` input changes.
• Every time the effect re-runs, the onCleanup function will call the callback function passed to it.
• Our callback function will unsubscribe from the previous subscription. (So, it will behave like the `switchMap` operator in RxJS)
• When the API call returns, we set the value of the `favoriteImages` signal.

Problem

What we are trying to do in the above example is to have some derived state based on the user `favoriteImages` ids. So, using an effect may not be the straightforward way to do this, or we may forget to unsubscribe from our subscription.

One other solution is to use `toObservable` helper function.

export class UserComponent {
  private imagesService = inject(ImagesService);

  user = input.required<User>();

  favoriteImages = toSignal(toObservable(this.user).pipe(
    switchMap(user => this.imagesService.getImages(user.favoriteImages))
  ), { initialValue: [] });
}

This is a better solution, but it’s not perfect. What happens if we include some other input and we need to include it in our API call? We will have to use `combineLatest` operator.

export class UserComponent {
  private imagesService = inject(ImagesService);

  user = input.required<User>();
  otherInput = input.required<string>();

  favoriteImages = toSignal(combineLatest([
    toObservable(this.user),
    toObservable(this.otherInput)
  ]).pipe(
    switchMap(([user, otherInput]) => this.imagesService.getImages(user.favoriteImages, otherInput))
  ), { initialValue: [] });
}

This gets messy very quickly! Because we start to include more and more rxjs operators, and we have to use `toObservable` and `toSignal` everywhere.

We can do better!

Building ComputedAsync

We want our `computedAsync` function to behave like the `computed` function, but it should handle async operations. Basically, it should return a signal that will have the value of the async operation.

favoriteImages = computedAsync(() => 
  this.imagesService.getImages(this.user().favoriteImages)
);

We want to return an observable (or promise), and we want the `computedAsync` function to handle the subscription and unsubscribe from it.

Handling the callback function

We want the developer to be able to pass either an observable or a promise, or just normal value. So, we need to handle all of these cases.

Here are the possible cases:

type ComputationResult<T> = Promise<T> | Observable<T> | T | undefined;

We want to accept a callback fn and return a Signal. So, we need to accept a callback function that will return a `ComputationResult<T>`.

export function computedAsync<T>(
    computation: () => ComputationResult<T>
): Signal<T> {
  // ...
}

Handling the current value and the result

We need to handle the current value and to return the result of the computation. We can use a `WritableSignal` to handle the current value and a computed signal to return the result of the computation.

export function computedAsync<T>(
    computation: () => ComputationResult<T>
): Signal<T> {
  const sourceValue = signal<T | undefined>(undefined);
  return computed(() => sourceValue()!);
}

Handling the computation

Because the computation will include signals, and the only way to listen to signal changes is by using `effect`, we need to use `effect` to handle the computation.

import { isObservable } from 'rxjs';

export function computedAsync<T>(
    computation: () => ComputationResult<T>
): Signal<T> {
  const sourceValue = signal<T | undefined>(undefined);

  effect(() => {
    const value = computation(); // store the result of the computation

    // handle the result if it's an observable or a promise or a normal value
    if (isObservable(value) || isPromise(value)) {
      // TODO: handle observable and promise
    } else {
      // TODO: handle normal value
    }
  });

  return computed(() => sourceValue()!);
}

// helper function to check if the value is a promise
function isPromise<T>(value: any): value is Promise<T> {
 return value && typeof value.then === 'function';
}

But, `effect` depends on the `DestroyRef` token, so it needs to be in an injection context, or we need to pass an injector to it. Let’s handle that.

Handling injection context

I will use the assertInjector helper function (created by Chau Tran) provided in the `ngxtension` library.

The `assertInjector` function will check if the injector is provided, and if it’s not, it will throw an error. In the third argument, we can pass a callback function that will be called in the injection context.

Let’s create a `ComputedAsyncOptions` interface that will include the injector and the equal function (that the normal `computed` function also includes).

interface ComputedAsyncOptions<T> extends CreateComputedOptions<T> {
 injector?: Injector;
}

Now, we can use the `assertInjector` function.

export function computedAsync<T>(
    computation: () => ComputationResult<T>,
    options?: ComputedAsyncOptions<T>
): Signal<T> {
  return assertInjector(computedAsync, options?.injector, () => {
    // here we can safely use effect and inject function because we are in an injection context
     effect(() => { /* ...  */ }, { injector: options?.injector });
  });
}

Handling the subscription

Just like we have a `sourceValue` signal to handle the current value, we need a `sourceEvent$` observable to handle the subscription. We will use a `Subject` to handle the subscription.

We want our value of the `sourceEvent$` to be either a promise or an observable.

const sourceEvent$ = new Subject<Promise<T> | Observable<T>>();

Let’s subscribe to the `sourceEvent$` and set the value of the `sourceValue` signal.

We also have to take care of flattening the observable, because we will pass an observable or promise to our `sourceEvent$`.

That’s why we will use `switchMap` operator to flatten the observable.

As a side effect, `switchMap` will also unsubscribe from the previous subscription 🎉.

const sourceResult = sourceEvent$
    .pipe(switchMap(s$ => s$))
    .subscribe({
        // set the value of the sourceValue signal when the source$ emits a value
        next: (value) => sourceValue.set(value),
        error: (error) => {
            // NOTE: Error should be handled by the user (using catchError or .catch())
            sourceValue.set(error);
        }
    });

Having `switchMap(s$ => s$)` can be replaced with `switchAll()` operator.

Thanks to Petrus Nguyễn Thái Học and Lucas Garcia for pointing that out.

const sourceResult = sourceEvent$
    .pipe(switchAll())
    .subscribe();

Handling the subscription cleanup

Because we subscribed to the `sourceEvent$` observable, we need to unsubscribe from it. We can use the `DestroyRef` token to handle that. `DestroyRef` has an `onDestroy` method that will call the callback function passed to it when the current injection context is destroyed, in our case, when the component is destroyed.

export function computedAsync<T>(
    computation: () => ComputationResult<T>,
    options?: ComputedAsyncOptions<T>
): Signal<T> {
  return assertInjector(computedAsync, options?.injector, () => {
    const destroyRef = inject(DestroyRef);

 const sourceEvent$ = new Subject<Promise<T> | Observable<T>>();

    effect(() => { /* ...  */ });

    const sourceResult = source$.subscribe(/* ... */);

    destroyRef.onDestroy(() => {
      sourceResultSubcription.unsubscribe();
    });
  });
}

That’s it! We subscribe to get the value and we unsubscribe when the component is destroyed.

Handling the returned observable or promise in the computation

This is currently how `computedAsync` looks like:

export function computedAsync<T>(
    computation: () => ComputationResult<T>,
    options?: ComputedAsyncOptions<T>
): Signal<T> {
  return assertInjector(computedAsync, options?.injector, () => {
    const destroyRef = inject(DestroyRef);

    const sourceValue = signal<T | undefined>(undefined);

 const sourceEvent$ = new Subject<Promise<T> | Observable<T>>();

    effect(() => {
        const value = computation(); // store the result of the computation

        // handle the result if it's an observable or a promise or a normal value
        if (isObservable(value) || isPromise(value)) {
            // TODO: handle observable and promise
        } else {
            // TODO: handle normal value
        }
    });

    const sourceResult = sourceEvent$
        .pipe(switchAll())
        .subscribe({
            next: (value) => sourceValue.set(value),
            error: (error) => sourceValue.set(error)
        });

    destroyRef.onDestroy(() => {
      sourceResultSubcription.unsubscribe();
    });

    return computed(() => sourceValue()!);
  });
}

Let’s handle the TODOs in the above code.

First, let’s handle the normal value case. We just need to set the value of the `sourceValue` signal.

effect(() => {
  const value = computation(); // store the result of the computation

  // handle the result if it's an observable or a promise or a normal value
  if (isObservable(value) || isPromise(value)) {
      // TODO: handle observable and promise
  } else {
      sourceValue.set(value);
  }
});

This will throw an error, because we cannot set the value of a signal inside an effect, without first enabling it for the effect.

effect(() => {
    // ...
}, { allowSignalWrites: true }) // enable signal writes

But, there’s another way to solve this problem. We can use the `untracked` function to set the value of the signal without enabling it for the effect (this is basically doing the same thing as the above code). Read more about this trick here.

Let’s use it:

untracked(() => sourceValue.set(value));

Let’s handle the observable and promise case. Just like we set the value in the signal, we need to `next` to the `sourceEvent$` observable.

effect(() => {
    const value = computation(); // store the result of the computation

    // handle the result if it's an observable or a promise or a normal value
    if (isObservable(value) || isPromise(value)) {
        sourceEvent$.next(value);
    } else {
        untracked(() => sourceValue.set(value));
    }
});

This may cause some issues, if we just leave it like that. How so?

Look at this example:

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  someValue = signal<string>('');

  favoriteImages = computedAsync(() => {
    return this.imagesService.getImages(this.user().favoriteImages).pipe(
       tap(() => this.someValue.set('some value'))
    );
  });
}

The `someValue` signal will be set inside our computation, but our computation is inside an effect, basically, we are setting the value of a signal inside an effect. This will throw an error. So, we need to untrack the `sourceEvent$.next()`.

effect(() => {
    const value = computation(); // store the result of the computation

    // handle the result if it's an observable or a promise or a normal value
    if (isObservable(value) || isPromise(value)) {
        untracked(() => sourceEvent$.next(value));
    } else {
        untracked(() => sourceValue.set(value));
    }
});

And now, our `computedAsync` function is complete 🎉!

Initial value

By default, the initial value of the `sourceValue` signal is `undefined`. But, we can pass an initial value to the `computedAsync` function.

interface ComputedAsyncOptions<T> extends CreateComputedOptions<T> {
 initialValue?: T;
 injector?: Injector;
}

export function computedAsync<T>(
    computation: () => ComputationResult<T>,
    options?: ComputedAsyncOptions<T>
): Signal<T> {
  return assertInjector(computedAsync, options?.injector, () => {
    // ...
    const sourceValue = signal<T | undefined>(options?.initialValue ?? undefined);
    // ...
  });
}

Now, we can pass an initial value to the `computedAsync` function.

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  favoriteImages = computedAsync(() => {
    return this.imagesService.getImages(this.user().favoriteImages);
  }, { initialValue: [] });
}

Handling race conditions (behavior)

Currently, we use only `switchAll` operator to handle the subscription and it will cancel the previous calls. But the devs may want to have a different behavior, and for this, we can add a `behavior` option to the `computedAsync` function.

type ComputedAsyncBehavior = 'switch' | 'merge' | 'concat' | 'exhaust';

interface ComputedAsyncOptions<T> extends CreateComputedOptions<T> {
 initialValue?: T;
 injector?: Injector;
 behavior?: ComputedAsyncBehavior;
}

We can use the `behavior` option to handle the subscription.

Let’s create a `createFlattenObservable` function that will handle the operator based on the `behavior` option.

function createFlattenObservable<T>(
 source: Subject<Promise<T> | Observable<T>>,
 behavior: ComputedAsyncBehavior,
): Observable<T> {
 const KEY_OPERATOR_MAP = {
  merge: mergeAll,
  concat: concatAll,
  exhaust: exhaustAll,
  switch: switchAll,
 };

 return source.pipe(KEY_OPERATOR_MAP[behavior]());
}

Now, we can use the `createFlattenObservable` function to handle the subscription.

const source$: Observable<T> = createFlattenObservable(
    sourceEvent$,
    options?.behavior ?? 'switch',
);

By default, we use `switch` behavior, but we can pass a different behavior.

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  favoriteImages = computedAsync(() => 
    this.imagesService.getImages(this.user().favoriteImages), 
    { initialValue: [], behavior: 'merge' }
  );
}

Because rxjs operators also support Promises, we can pass a promise to the `sourceEvent$` and it will handle it, just like it handles observables.

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  favoriteImages = computedAsync(() => 
    fetch(`https://localhost/api/images/${this.user().favoriteImages}`).then(res => res.json()), 
    { initialValue: [], behavior: 'merge' }
  );
}

How to use the previous value in the computation?

Inside the effect, we can get the current value from the `sourceValue` signal. But, reading a signal inside an effect, registers it as a dependency. So, we need to untrack it first, then we can pass it to the `computation` function.

effect(() => {
    const currentSourceValue = untracked(() => sourceValue());
    const value = computation(currentSourceValue); // store the result of the computation
    // ...  
}); 

This enables us to use the previous value in the computation.

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  favoriteImages = computedAsync((previousFavoriteImages) => {
      if (previousFavoriteImages) { /* do something */ }
      return this.imagesService.getImages(this.user().favoriteImages);
  }, 
  { initialValue: [], behavior: 'merge' });
}

Use computedAsync from ngxtension

The `computedAsync` function is available in the `ngxtension` library.

npm install ngxtension
# or
yarn add ngxtension

Then, you can import it from `ngxtension` library.

import { computedAsync } from 'ngxtension/computed-async';

And use it like this:

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  favoriteImages = computedAsync(() => 
    this.imagesService.getImages(this.user().favoriteImages), 
    { initialValue: [] }
  );
}

📚 Documentation is available here.

🔨 Read more about the development of `computedAsync` here.

Thanks for reading!

If this article was interesting and useful to you, and you want to learn more about Angular, support me by buying me a coffee ☕️ or follow me on X (formerly Twitter) @Enea_Jahollari where I tweet and blog a lot about Angular latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more. 💎

Building ComputedAsync for Signals in Angular was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Angular has gone through a lot of changes in the past few years. Since the release of 2.0 Angular embraced decorators and used them to annotate parts of code that should be processed by Angular. We have Component, Directive, Pipe, and Injectable decorators for classes, etc. We also have Input and Output decorators that are used to define the inputs and outputs of a component (public API of a component).

In this article, we will see how Angular is going to reduce the decorator usage for Inputs by using signal inputs and how it will make the code more readable, and easier to understand.

Decorator Inputs

Let’s start with a simple example of a component that has an input property.

@Component({
  selector: 'user',
  template: `
      <h1>{{ user.name }}</h1>
      <p>{{ user.email }}</p>
  `,
})
export class UserComponent {
  @Input() user: User;
}

The @Input decorator is used to define an input property. The user property is an input property and it is used to pass a User object to the component. The User object is then used to render the name and email of the user.

The code above looks ok, but it has a few issues 🤔.

Just by looking at the type, we can see that the user will always be set (it’s not optional). But, we’re still allowed to use the component as:

<user />

However, this will result in an error at runtime because the user property is not set.

Error: Cannot read property 'name' of undefined

We can fix this by making the `user` property optional:

@Input() user?: User;

Now, we need to check if the user is set before using it:

@if (user) {
  <h1>{{ user.name }}</h1>
  <p>{{ user.email }}</p>
}

or by using the ? operator:

<h1>{{ user?.name }}</h1>
<p>{{ user?.email }}</p>

This is a lot of code for something that should be simple. We can fix this by using a default value:

@Input() user: User = { name: '', email: '' };

Now, we can use the `user` property without checking if it is set. But, what if the `user` object has a lot more fields? We would need to set all of them to a default value. This is not a good solution 🙃.

What we can do is to make the user input required if it’s a core part of the component. We can do this by using the `{ required: true }` option:

@Input({ required: true }) user: User;

This will make the `user` input required and we will get an error if we don’t set it.

<user />

This will result in an error:

Error: Required input 'user' from component UserComponent must be specified.

How can we make these errors appear earlier?

What we can do is enable `strictPropertyInitialization` in the `tsconfig.json` file. This will make the compiler check if all properties are initialized. The code below will result in an error:

// error: Property 'user' has no initializer and is not assigned in the constructor.
@Input() user: User; 

To fix this TS error, we either need to set a default value or just set it to `undefined` or `null`:

@Input() user: User | undefined;
// or
@Input() user: User | null = null;
// or
@Input() user?: User;

And then, just like before we need to check if the `user` is set before using it.

If we try to make the `user` input required, we will get the same error:

// error: Property 'user' has no initializer and is not definitely assigned in the constructor.
@Input({ required: true }) user: User; 

We can fix this by using the ! operator:

@Input({ required: true }) user!: User;

This is fine because we’re telling the compiler that the `user` property will be set before we use it.

Signal Inputs

In Angular v17.1, a new feature will be introduced — Signal Inputs. This is how they will look like:

export class UserComponent {
  user = input<User>();
}

The code above is equivalent to the code below:

export class UserComponent {
  @Input() user: User | undefined;
}

The difference is that by default if we don’t make the input required, the `user` property will be set to `undefined`. This is the first thing that signal inputs protect us from ✨.

Required Inputs

If we want to make the `user` input required, we can do it by using the `required` option:

export class UserComponent {
  user = input.required<User>();
}

This is equivalent to:

export class UserComponent {
  @Input({ required: true }) user!: User;
}

What we can also do is to set a default value:

export class UserComponent {
  user = input<User>({ name: '', email: '' });
}

Because the user will always be instantiated, we won’t need to use the ! (non null assertion) anymore 🚀

As we can see, we don’t have to fight with Angular typings and Typescript anymore or have to understand all the inner workings of Angular. We can just use the `input` function and we’re good to go 🚀.

Why doesn’t Angular make all decorator inputs required by default?

The reason is that Angular is used in a lot of different projects. Making all inputs required by default will break a lot of projects. That’s why we need to opt-in for this feature.

Deriving state from inputs

Input setter with a method call

With class fields, what we did to derive the state was to use input setters and call a method that will derive the state from the inputs.

// deriving state from inputs with input setter and calling a method
export class UserComponent {
  _user: User | undefined;
  _images: string[] = [];

  favoriteImages: string[] = [];

  @Input() set user(user: User) {
    this._user = user;
    this.updateFavoriteImages();
  }

  @Input() set images(images: string[]) {
    this._images = images;
    this.updateFavoriteImages();
  }

  private updateFavoriteImages() {
    if (this._user && this._images) {
      this.favoriteImages = this._images.filter(x => this._user.favoriteImages.includes(x.name));
    }
  }
}

Input setter with BehaviorSubject

The input setter has the issue of not having access to all input changes, that’s why we used it mostly with BehaviorSubjects and handled the racing conditions with rxjs operators.

// deriving state from inputs with input setter and BehaviorSubject
export class UserComponent {
  user$ = new BehaviorSubject<User | undefined>(undefined);
  images$ = new BehaviorSubject<string[]>([]);

  favoriteImages$ = combineLatest([this.user$, this.images$]).pipe(
    map(([user, images]) => {
      if (user && images) {
        return images.filter(x => user.favoriteImages.includes(x.name));
      }
      return [];
    })
  );

  @Input() set user(user: User) {
    this.user$.next(user);
  }

  @Input() set images(images: string[]) {
    this.images$.next(images);
  }
}

ngOnChanges

ngOnChanges on the other hand, is called for every input change and it has access to all the inputs.

// deriving state from inputs with ngOnChanges

export class UserComponent implements OnChanges {
  @Input() user: User | undefined;
  @Input() images: string[] = [];

  favoriteImages: string[] = [];

  ngOnChanges(changes: SimpleChanges) {
    if (changes.user || changes.images) {
      this.updateFavoriteImages();
    }
  }

  private updateFavoriteImages() {
    if (this.user && this.images) {
      this.favoriteImages = this.images.filter(x => this.user.favoriteImages.includes(x.name));
    }
  }
}

These are some of the patterns that we used to derive state from inputs.

Signals 🚦

Then signals were introduced and we started to use them to derive state from inputs.

// deriving state from inputs with signals

export class UserComponent {
  user = signal<User | undefined>(undefined);
  images = signal<string[]>([]);

  favoriteImages = computed(() => {
    const user = this.user();
    if (user && this.images().length) {
      return this.images().filter(x => user.favoriteImages.includes(x.name));
    }
    return [];
  });

  @Input({ alias: 'user' }) set _user(user: User) {
    this.user.set(user);
  }

  @Input({ alias: 'images' }) set _images(images: string[]) {
    this.images.set(images);
  }
}

We just refactored the code to use signals instead of BehaviorSubjects. And computed instead of combineLatest.

Signal Inputs

Now, with signal inputs, we can just use the `input` function and we’re good to go 🚀.

// deriving state from inputs with signal inputs

export class UserComponent {
  user = input.required<User>(); // Let's make the user input required for this example
  images = input<string[]>([]);

  favoriteImages = computed(() => {
    const user = this.user();
    if (user && this.images().length) {
      return this.images().filter(x => user.favoriteImages.includes(x.name));
    }
    return [];
  });
}

Inputs + API calls

This was easy to do with BehaviorSubjects because we can just pipe the observables and handle the racing conditions with rxjs operators.

// inputs + api calls with BehaviorSubjects
export class UserComponent {
  private imagesService = inject(ImagesService);
  user$ = new BehaviorSubject<User | undefined>(undefined);

  favoriteImages$ = this.user$.pipe(
    switchMap(user => {
      if (user) {
        return this.imagesService.getImages(user.favoriteImages);
      }
      return of([]);
    })
  );

  @Input() set user(user: User) {
    this.user$.next(user);
  }
}

With `ngOnChanges` we can do the same thing, but we need to handle the racing conditions ourselves.

// inputs + api calls with ngOnChanges
export class UserComponent implements OnChanges, OnDestroy {
  private imagesService = inject(ImagesService);
  @Input() user: User | undefined;

  favoriteImages: string[] = [];

  private currentSub?: Subscription;

  ngOnChanges(changes: SimpleChanges) {
    if (changes.user) {
      this.updateFavoriteImages();
    }
  }

  private updateFavoriteImages() {
    if (this.user) {
      this.currentSub?.unsubscribe();

      this.currentSub = this.imagesService
        .getImages(this.user.favoriteImages)
        .subscribe(images => (this.favoriteImages = images));
    }
  }

  ngOnDestroy() {
    // unsubscribe from the observable when the component is destroyed
    this.currentSub?.unsubscribe(); 
  }
}

That’s too much code for something that should be simple. Also, if the API call depends on more than one input, we need to handle the racing conditions ourselves ⚠️.

Signal Inputs + API calls

To listen to input changes, we use the `effect` function.

In v17, `effect` is scheduled to run after all the inputs are initialized. So, it means even if we have an effect on the constructor, we can be sure that all the inputs are initialized (inside of it).

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  constructor() {
    console.log('constructor - user', this.user()); // user is undefined here
    effect(() => {
      console.log('effect - user', this.user());
    });
  }

  ngOnInit() {
    console.log('init - user', this.user()); // user is defined here
  }
}

<app-user [user]="user" />

This code will result in the following output:

constructor - user undefined
init        - user { name: 'John' };
effect      - user { name: 'John' };

Because of this, we can use the `effect` function to make API calls.

// inputs + api calls with signal inputs

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  favoriteImages = signal<string[]>([]);

  constructor() {
    effect((onCleanup) => {
      const sub = this.imagesService.getImages(this.user().favoriteImages).subscribe(images => {
        this.favoriteImages.set(images);
      });
      onCleanup(() => sub.unsubscribe())
    });
  }
}

This is great until we have to manage multiple input changes and derive state from them, while also maintaining the subscriptions .

computedFrom (ngxtension) to the rescue 🛟

computedFrom was born out of the need to derive state from multiple sources (observables, signals, signals from inputs) and also to manage the subscriptions cleanly (without having to subscribe/unsubscribe manually ✅).

Read the whole story here:

A sweet spot between signals and observables 🍬

This is how we can use it to derive state from inputs and API calls:

// inputs + api calls with signal inputs + computedFrom

export class UserComponent {
  private imagesService = inject(ImagesService);
  user = input.required<User>();

  favoriteImages = computedFrom(
    [this.user], // sources
    switchMap(([user]) => this.imagesService.getImages(user.favoriteImages)), // side effect + computation
    { initialValue: [] } // options
  );
}

If you have more sources, you can just add them to the array:

favoriteImages = computedFrom(
  [this.user, this.imageOptions, /* ... more sources here */ ]
  switchMap(([user, options]) => 
    this.imagesService.getImages(user.favoriteImages, options)
  ),
  { initialValue: [] } 
);

Enea Jahollari 🅰 on Twitter: "Using ngxtension utils to power apps 🚀? Look at this snippet doing an API call powered by signals on the outside and observables (HTTP call) on the inside.- injectQueryParams, injectParams -> router signals- computedFrom -> combineLatest with signalsRead more on the docs... pic.twitter.com/yfbrm8DPgw / Twitter"

Using ngxtension utils to power apps 🚀? Look at this snippet doing an API call powered by signals on the outside and observables (HTTP call) on the inside.- injectQueryParams, injectParams -> router signals- computedFrom -> combineLatest with signalsRead more on the docs... pic.twitter.com/yfbrm8DPgw

Migrating to Signal Inputs

You can go over all your inputs and start refactoring every input and its references one by one, or you can use some migration schematics that handle most of the basic usage patterns for you.

The ngxtension library publishes some schematics you can use in an Angular or Nx workspace.

To use it you just have to run these two commands:

npm install ngxtension
ng g ngxtension:convert-signal-inputs

Find more about it in the docs: Ngxtension Signal Inputs Migration by Chau Tran 🪄

To sum up

With signal inputs, we can just use the `input` function and we’re good to go 🚀. We don’t have to fight with Typescript anymore or have to understand all the inner workings of Angular. We can just use the `input` function to derive state directly from inputs, to manage API calls more easily, and if we don’t want to maintain any glue code at all, computedFrom (ngxtension) is there to help us.

The article was reviewed by:

• Matthieu Riegler 🧑🏻‍💻 (Make sure to follow him on Twitter for everything Angular)

Other articles to read regarding signal inputs:

• Diving into Type System behind Angular Signal Inputs
• Revolutionizing Angular: Introducing the New Signal Input API

Get better at Modern Angular ⚡️

Master the latest features to build modern applications. Learn how to use standalone components, function guards & interceptors, signals, the new inject method, and much more.

🔗 Modern Angular workshop from Push-Based.io

Thanks for reading!

If this article was interesting and useful to you, and you want to learn more about Angular, support me by buying me a coffee ☕️ or follow me on X (formerly Twitter) @Enea_Jahollari where I tweet and blog a lot about Angular latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more. 💎

Angular Signal Inputs are here to change the game 🎲 was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Angular is a component-driven framework. And just like every other framework out there, it is supposed to show the data to the user and refresh the view when the data changes.

Over time, we build more and more components and compose them together, and we may end up with a component tree like the one below.

But, how does Angular know when to refresh the view? How does it know when the data changes? How does it know when to run the change detection?

Change detection with synchronous code

Let’s start with a simple example. We have a component with a property name and a method changeName. When we click the button, we call the changeName method and change the name property.

@Component({
  template: `
    <button (click)="changeName()">Change name</button>
    <p>{{ name }}</p>
  `
})
export class AppComponent {
  name = 'John';

  changeName() {
    this.name = 'Jane';
  }
}

When we click the button, the changeName method is called, and because everything is wrapped by Angular, we can safely assume that after the name is changed, Angular can run some code to update the view (and everything will be in sync).

⚠️ Imaginary under the hood Angular code:

component.changeName();
// This code is run  Angular will run change detection for the whole component tree because we may have updated some data in a service that is used by other components
angular.runChangeDetection(); 

This works fine! But, most of the time when we change the data, we don’t do it synchronously. We usually make an HTTP request, or have some timers, or wait for some other events to happen before updating the data. And that’s where the problems start.

Change detection with asynchronous code

Now, let’s say that we want to change the name after 1 second. We can do that with the setTimeout function.

@Component({
  template: `
    <button (click)="changeName()">Change name</button>
    <p>{{ name }}</p>
  `
})
export class AppComponent {
  name = 'John';

  changeName() {
    setTimeout(() => {
      this.name = 'Jane';
    }, 1000);
  }
}

When we click the button, the changeName method is called, and the setTimeout function is called. The setTimeout function will wait for 1 second and then call the callback function. The callback function will change the name to Jane.

And now, let’s add the same imaginary under-the-hood Angular code as before.

⚠️ Imaginary under the hood Angular code:

component.changeName(); // uses setTimeout inside

// this code is run immediately after the changeName method is called
angular.runChangeDetection();

Because of the call stack, the setTimeout callback will be called after the angular.runChangeDetection method. So, Angular ran the change detection but the name was not changed yet. And that’s why the view will not be updated. And that’s a broken application ⚠️. (In reality, it’s not, because we have 👇)

Zone.js to the rescue

Zone.js has been around since the early days of Angular 2.0. It is a library that monkey patches the browser APIs and enables us to hook into the lifecycle of the browser events. What does that mean? It means that we can run our code before and after the browser events.

setTimeout(() => {
  console.log('Hello world');
}, 1000);

The code above will print Hello world after 1 second. But, what if we want to run some code before or after the setTimeout callback? You know, for business reasons 😄. A framework called Angular may want to run some code before and after the setTimeout callback.

Zone.js enables us to do that. We can create a zone (Angular does create a zone too) and hook into the setTimeout callback.

const zone = Zone.current.fork({
  onInvokeTask: (delegate, current, target, task, applyThis, applyArgs) => {
    console.log('Before setTimeout');
    delegate.invokeTask(target, task, applyThis, applyArgs);
    console.log('After setTimeout');
  }
});

To run our setTimeout inside the zone, we need to use the zone.run() method.

zone.run(() => {
  setTimeout(() => {
    console.log('Hello world');
  }, 1000);
});

Now, when we run the code above, we will see the following output.

Before setTimeout
Hello world
After setTimeout

And that’s how zone.js works. It monkey patches the browser APIs and enables us to hook into the lifecycle of the browser events.

Zone.js + Angular

Angular loads zone.js by default in every application and creates a zone called NgZone. NgZone includes an Observable called onMicrotaskEmpty. This observable emits a value when there are no more microtasks in the queue. And that’s what Angular uses to know when all the asynchronous code is finished running and it can safely run the change detection.

Let’s look at the underlying code:

// ng_zone_scheduling.ts NgZoneChangeDetectionScheduler
this._onMicrotaskEmptySubscription = this.zone.onMicrotaskEmpty.subscribe({
    next: () => this.zone.run(() => this.applicationRef.tick())
});

What we see in the code above is that Angular will call the applicationRef.tick() method when the onMicrotaskEmpty observable emits a value. What’s this tick method 🤔? Do you remember the runChangeDetection method from the imaginary under-the-hood Angular code? Well, the tick method is the runChangeDetection method. It runs the change detection for the whole component tree synchronously.

But now, Angular knows that all the asynchronous code has finished running and it can safely run the change detection.

tick(): void {
    // code removed for brevity
    for (let view of this._views) {
        // runs the change detection for a single component
        view.detectChanges(); 
    }
}

The tick method will iterate over all the root views (most of the time we have only one root view/component which is AppComponent) and run detectChanges synchronously.

Component Dirty marking

One other thing Angular does is that it marks the component as dirty when it knows something inside the component changed.

These are the things that mark the component as dirty:

• Events (click, mouseover, etc.)

Every time we click a button with a listener in the template, Angular will wrap the callback function with a function called wrapListenerIn_markDirtyAndPreventDefault. And as we can see from the name of the function 😅, it will mark the component as dirty.

function wrapListener(): EventListener {
  return function wrapListenerIn_markDirtyAndPreventDefault(e: any) {
    // ... code removed for brevity
    markViewDirty(startView); // mark the component as dirty
  };
}

• Changed inputs

Also, while running the change detection, Angular will check if the input value of a component has changed (=== check). If it has changed, it will mark the component as dirty. Source code here.

setInput(name: string, value: unknown): void {
    // Do not set the input if it is the same as the last value
    if (Object.is(this.previousInputValues.get(name), value)) {
        return;
    }

    // code removed for brevity
    setInputsForProperty(lView[TVIEW], lView, dataValue, name, value);
    markViewDirty(childComponentLView); // mark the component as dirty
}

• Output emissions

To listen to output emissions in Angular we register an event in the template. As we saw before, the callback fn will be wrapped and when the event is emitted, the component will be marked as dirty.

Let’s see what this markViewDirty function does.

/**
 * Marks current view and all ancestors dirty.
 */
export function markViewDirty(lView: LView): LView|null {
  while (lView) {
    lView[FLAGS] |= LViewFlags.Dirty;
    const parent = getLViewParent(lView);
    // Stop traversing up as soon as you find a root view that wasn't attached to any container
    if (isRootView(lView) && !parent) {
      return lView;
    }
    // continue otherwise
    lView = parent!;
  }
  return null;
}

As we can read from the comment, the markViewDirty function will mark the current view and all ancestors dirty. Let’s see the image below to better understand what that means.

So, when we click the button, Angular will call our callback fn (changeName) and because it’s wrapped with the wrapListenerIn_markDirtyAndPreventDefault function, it will mark the component as dirty.

As we said before, Angular uses zone.js and wraps our app with it.

After dirty marking to the top, wrapListenerIn_markDirtyAndPreventDefault fires and triggers zone.js

Because Angular is listening to the onMicrotaskEmpty observable, and because the (click) registers an event listener, which zone has wrapped, zone will know that the event listener has finished running and it can emit a value to the onMicrotaskEmpty observable.

onMicrotaskEmpty tells Angular it’s time to run the change detection.

Component binding refresh

The moment Angular runs the change detection it will check every component from top to bottom. It will go over all the components (dirty and non-dirty) and check their bindings. If the binding has changed, it will update the view.

But, why does Angular check all the components 🤔? Why doesn’t it check only the dirty components 🤔?

Well, because of the change detection strategy.

OnPush Change Detection

Angular has a change detection strategy called OnPush. When we use this strategy, Angular will only run the change detection for a component that is marked as dirty.

First, let’s change the change detection strategy to OnPush.

@Component({
  // ...
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserCard {}

Let’s look at the graphic below to better understand how the change detection works with the OnPush strategy.

Let’s do the same thing as before. Click a button in the component and change the name.

First, we will have the Dirty Marking phase.

Then, the event listener will notify zone.js.

When everything async has finished running, onMicrotaskEmpty will fire.

Now, Angular will run the tick method, and what it will do is traverse all components from top to bottom and check each component.

If the component is:

• OnPush + Non-Dirty -> Skip
• OnPush + Dirty -> Check bindings -> Refresh bindings -> Check children

As we can see, by using OnPush we can skip parts of the tree that we know haven’t had any changes.

OnPush + Observables + async pipe

When we work with Angular, observables have been our number one tool to manage data and state changes. To support observables, Angular provides the async pipe. The async pipe subscribes to an observable and returns the latest value. To let Angular know that the value has changed, it will call the markForCheck method that comes from the ChangeDetectorRef class (the component’s ChangeDetectorRef).

@Pipe()
export class AsyncPipe implements OnDestroy, PipeTransform {
  constructor(ref: ChangeDetectorRef) {}

  transform<T>(obj: Observable<T>): T|null {
    // code removed for brevity
  }

  private _updateLatestValue(async: any, value: Object): void {
    // code removed for brevity
    this._ref!.markForCheck(); // <-- marks component for check
  }
}

I’ve written more about it here (create async pipe from scratch and understand how it works):

Async pipe is not pure 🤯

And what the markForCheck method does is that it will just call the markViewDirty function that we saw before.

// view_ref.ts
markForCheck(): void {
  markViewDirty(this._cdRefInjectingView || this._lView);
}

So, the same as before, if we use observables with async pipe in the template it will act the same as if we used the (click) event. It will mark the component as dirty and Angular will run the change detection.

OnPush + Observables + Who is triggering zone.js?

If our data changes without our interaction (click, mouseover etc.) probably there is a setTimeout or setInterval or an HTTP call being made somewhere under the hood that triggers zone.js.

Here’s how we can easily break it 🧨

@Component({
  selector: 'todos',
  standalone: true,
  imports: [AsyncPipe, JsonPipe],
  template: `{{ todos$ | async | json }}`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TodosComponent {
  private http = inject(HttpClient);
  private ngZone = inject(NgZone);

  todos$ = of([] as any[]);

  ngOnInit() {
    this.ngZone.runOutsideAngular(() => {
      setTimeout(() => {
        // this will be updated, but there's nothing triggering zonejs
        this.todos$ = this.getTodos();
      });
    });
  }

  getTodos() {
    return this.http
      .get<any>('https://jsonplaceholder.typicode.com/todos/1')
      .pipe(shareReplay(1));
  }
}

What we have done here is:

• In ngOnInit, we have used ngZone.runOutsideAngular() an API that allows us to run things outside the Angular zone.
• We use setTimeout (to skip the first task being run and also because Angular runs change detection at least once by default) and inside the setTimeout, we assign a value to the observable (yay we have a change).
• Because setTimeout won’t run inside the zone, also the API call will be made outside the zone because the code is run inside runOutsideAngular, there is nothing notifying zonejs that something changed.
• Run this code in your app and see that only “[]” will be shown in the browser.
• Broken State 🧨!

Not great 😄! But, one other thing that we start questioning is:

Why do we need to mark all the ancestors dirty?

The reason for this is simple, if we don’t mark all ancestors as dirty, we can get a broken state even faster. How?

Let’s see the above example again, but now, mark only the component and its children as dirty.

So, we mark only the component that had the click and its children to be marked for check. The moment the tick happens it will get to the parent component which is OnPush, check that it’s not dirty, and skip it.

That’s how we get to a broken state again 🧨!

Why can’t we just run the change detection for the component that is marked as dirty?

We can do that using the detectChanges method in the ChangeDetectorRef class. But it has its drawbacks. Because that method runs change detection synchronously, it can cause performance issues. Because everything will be done in the same browser task, it may block the main thread and cause jank. Imagine detecting changes for a list of 100 items every 1 or 2 seconds. That’s a lot of work for the browser.

markForCheck vs detectChanges (coalesced run vs sync runs)

When we use markForCheck we just tell Angular that a component is dirty, and nothing else happens, so even if we call markForCheck 1000 times it’s not going to be an issue. But, when we use detectChanges, Angular will do actual work like checking bindings and updating the view if needed. And that’s why we should use markForCheck instead of detectChanges.

Can’t we schedule detectChanges in the next browser task?

We can, that’s what push pipe or rxLet directive from rx-angular does. It schedules the change detection in the next browser task. But, it’s not a good idea to do that for every component. Because, if we have a list of 100 items, and we schedule the change detection for every item, we will have 100 browser tasks. And that’s not good for performance either.

Signals 🚦

The frontend world is moving towards signals. Solid.js, Svelte, Vue, and Angular are creating their signal implementations. And that’s because signals are a better way to manage state and state changes.

Signals in Angular have brought a lot of DX benefits. We can easily create and derive state and also run side effects when the state changes using effects. We don’t have to subscribe to them, we don’t have to unsubscribe from them, and we don’t have to worry about memory leaks 🧯.

We can just call them and they will return their current value.

const name = signal('John'); // create a signal with initial value
const upperCaseName = computed(() => name().toUpperCase()); // create a computed signal

effect(() => {
  console.log(name() + ' ' + upperCaseName()); // run side effect when name or upperCaseName changes
});

name.set('Jane'); // change the name

// Output:
// John JOHN
// Jane JANE

We can also use signals in the template just like normal function calls.

@Component({
  template: `
    <button (click)="name.set('Jane')">Change name</button>
    <p>{{ name() }}</p>
  `
})
export class AppComponent {
  name = signal('John');
}

If you ask if calling a function in the template is a good idea, I would say that it’s a good idea if the function call is cheap, and calling a signal is cheap. It’s just a function call that returns a value (without computing anything).

I’ve also written about it here:

It’s ok to use function calls in Angular templates!

Signals and Change Detection

In v17 Angular change detection got an upgrade 🚀!

Angular templates now understand signals as something more than function calls. Below is one of the PRs making this a reality.

feat(core): Mark components for check if they read a signal by atscott · Pull Request #49153 · angular/angular

Before we used the async pipe, so it would call the markForCheck method, and with signals, we just have to normally call them. Angular now will register an effect (consumer) that will listen to this signal and mark the template for check every time the signal changes.

The first benefit is that we don’t need async pipe anymore 🎉.

The second PR that improves change detection is this one:

fix(core): Ensure backwards-referenced transplanted views are refreshed by atscott · Pull Request #51537 · angular/angular

Which solved an issue not related to signals but to change detection itself (which I won’t explain in detail).

By using the mechanism introduced by it, we got the 3rd PR which added Glo-cal change detection (Global + Local change detection) (a term coined by my friend @Matthieu Riegler )

perf(core): Update LView consumer to only mark component for check by atscott · Pull Request #52302 · angular/angular

So let’s better understand glo-cal (local) change detection 👇

Local Change Detection (Targeted mode)

One of those PRs I linked above introduced two new flags in Angular.

How do they work?

When the template effect runs, Angular will run a function called markViewForRefresh which sets the current component flag to RefreshView and then calls markAncestorsForTraversal which will mark all the ancestors with HAS_CHILD_VIEWS_TO_REFRESH.

/**
 * Adds the `RefreshView` flag from the lView and updates HAS_CHILD_VIEWS_TO_REFRESH flag of
 * parents.
 */
export function markViewForRefresh(lView: LView) {
  if (lView[FLAGS] & LViewFlags.RefreshView) {
    return;
  }
  lView[FLAGS] |= LViewFlags.RefreshView;
  if (viewAttachedToChangeDetector(lView)) {
    markAncestorsForTraversal(lView);
  }
}

And here’s how it looks in the graph (updated tree structure to showcase more edge cases)👇

So, the component that has signal changes is marked with the orange color border and the parents now have the ⏬ icon to tell that they have child views to refresh.

NOTE: We still depend on zone.js to trigger change detection.

The moment zone.js kicks in (the same reasons as before) it will call appRef.tick() and then we will have top-down change detection with some differences and new rules!

Targeted Mode Rules

NgZone triggers change detection in GlobalMode (it will go top-down checking & refreshing all components)

In GlobalMode we check CheckAlways (normal component without any change detection strategy set) and Dirty OnPush components

What triggers TargetedMode?

• When in GlobalMode we encounter a Non-Dirty OnPush component, we switch to TargetedMode!

In TargetedMode:

• Only refresh a view if it has the RefreshView flag set
• DO NOT Refresh CheckAlways or regular Dirty flag views
• If we reach a view with RefreshView flag, traverse children in GlobalMode

Let’s go one by one on components.

1. Root component is a normal component (CheckAlways) so we just check & refresh bindings if needed and we continue to its children.

2. All CheckAlways components will continue to work the same as before.

3. OnPush will continue to work the same, so if it’s not marked as dirty it won’t be checked.

4. If we check the other component that is OnPush + HAS_CHILD_VIEWS_TO_REFRESH but not dirty we get our trigger for TargetedMode (check the rules above)

6. The component itself is not going to be refreshed, let’s go to the children

7. Then we reach a RefreshView component and we are on TargetedMode, which means we refresh the bindings. We also convert to GlobalMode to make sure CheckAlways children components also get refreshed correctly.

8. Now we are in GlobalMode and we have a CheckAlways component, so we just refresh normally)

That’s all about the new Targeted Change Detection.

If we look at the final tree, we can see that we skipped more components than before when we reach an OnPush component that is not dirty.

Targeted Change Detection = OnPush without footguns 🔫

You can play with all these change detection rules in this app by Mathieu Riegler 🔨

Understand Angular Change Detection

Zoneless Angular — Let’s remove zone.js from Angular

The moment we remove zone.js from Angular we are left with code that runs but doesn’t update anything in the view (The bootstrap time of zone.js and all the pressure it puts in the browser gets removed too! We also remove 15kb from the bundle size 😎). Because nothing is triggering appRef.tick().

But, Angular has some APIs that tell it that something changed. Which ones?

• markForCheck (used by async pipe)
• signal changes
• event handlers that mark view dirty
• setting inputs on components created dynamically with setInput()

Also, OnPush components already works with the idea that it needs to tell Angular that something changed.

So, instead of having zone.js schedule tick() we can have Angular schedule tick() when it knows something changed.

refactor(core): Add scheduler abstraction and notify when necessary by atscott · Pull Request #53499 · angular/angular

In this PR (experimental) we can see that markViewDirty now will notify the changeDetectionScheduler that something changed.

export function markViewDirty(lView: LView): LView|null {
  lView[ENVIRONMENT].changeDetectionScheduler?.notify();
  // ... code removed for brevity
}

The scheduler is supposed to schedule tick(), as we can see in this other experimental implementation of a zoneless scheduler.

Add zoneless scheduler to the ApplicationRef.isStable indicator by atscott · Pull Request #53579 · angular/angular

@Injectable({providedIn: 'root'})
class ChangeDetectionSchedulerImpl implements ChangeDetectionScheduler {
  private appRef = inject(ApplicationRef);
  private taskService = inject(PendingTasks);
  private pendingRenderTaskId: number|null = null;

  notify(): void {
    if (this.pendingRenderTaskId !== null) return;

    this.pendingRenderTaskId = this.taskService.add();
    setTimeout(() => {
      try {
        if (!this.appRef.destroyed) {
          this.appRef.tick();
        }
      } finally {
        const taskId = this.pendingRenderTaskId!;
        this.pendingRenderTaskId = null;
        this.taskService.remove(taskId);
      }
    });
  }
}

This is experimental, but we can see that basically, it will coalesce all notify() calls and run them only once (in this code is only once per macroTask — setTimeout, but maybe we get it only once per microTask — Promise.resolve())

What are we supposed to understand from this?

Apps that are currently using the OnPush change detection strategy will work fine in a zoneless angular world.

Zoneless Angular !== Glo-cal (local) change detection

Zoneless Angular is not the same as local change detection. Zoneless Angular is just removing zone.js from Angular and using the APIs that Angular already has to schedule tick().

Real Local change detection is a new feature that will allow us to run change detection for only a sub-tree of components (not the whole component tree) that currently use the OnPush change detection strategy.

Signals change detection (No OnPush, No Zone.js, Signals only)

One thing signal change detection will bring is native unidirectional data flow (two-way data binding without headaches).

Watch this video Rethinking Reactivity w/ Alex Rickabaugh | Angular Nation

While glo-cal change detection with OnPush and zoneless are great, with only signal components, we probably can do even better.

What if we didn’t have to use OnPush? Or mark the parents with HAS_CHILD_VIEWS_TO_REFRESH and run change detection for the whole component tree? What if we could just run change detection for the views inside components that have changed?

Read more in the RFC:

[Complete] Sub-RFC 3: Signal-based Components · angular angular · Discussion #49682

Happy New Year 2024! 🎉 A signals year for Angular 🚦!

This year Angular brought us a lot of new features. And I’m sure that next year will be even better.

Make sure to check out the

• Angular roadmap for 2024 🎉
• Angular Christmas Calendar 2023

Alex Rickabaugh on Twitter: "2024 for @Angular will be the Year of the Signal. / Twitter"

2024 for @Angular will be the Year of the Signal.

Credits where it’s due:

• Alex Rickabaugh for answering all my questions about Angular
• Andrew Scott for every PR he has created till now
• Chau Tran and Matthieu Riegler for the discussions about Angular internals
• Michael Hladky Julian Jandl Kirill Karnaukhov Edouard Bozon Lars Gyrup Brink Nielsen (RxAngular team)
• The whole Angular team for the wonderful job they have been doing!

Get better at Modern Angular ⚡️

Master the latest features to build modern applications. Learn how to use standalone components, function guards & interceptors, signals, the new inject method, and much more.

🔗 Modern Angular workshop from Push-Based.io

Thanks for reading!

I tweet and blog a lot about Angular (latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more). 💎

If this article was interesting and useful to you, and you want to learn more about Angular, give me a follow at @Enea_Jahollari or Medium. 📖

I’d appreciate it if you would support me by buying me a coffee ☕️. Thank you in advance 🙌

A change detection, zone.js, zoneless, local change detection, and signals story 📚 was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.