DEV Community

Cover image for Signals In Angular — Is RxJS Doomed?
Lorenzo Zarantonello for This is Angular

Posted on • Originally published at levelup.gitconnected.com

Signals In Angular — Is RxJS Doomed?

The Angular team is finally releasing the first comments and prototypes regarding bringing Signals, a new reactive primitive, to the core framework.

PR: feat(core): add Angular Signals to the public API

What You Should Know: TL;DR:

  • To some extent, Signals is powerful like RxJS but with a simpler syntax.
  • If implemented, it might change the way change detection work. Possibly, removing zone.js.
  • Signals are not going to replace RxJS any time soon.

What Are Signals?

A Signal is a source of value
Alex Rickabaugh

Signals have been popularized recently by Solid.js which describes them as follows:

Signals are the cornerstone of reactivity in Solid. They contain values that change over time; when you change a signal’s value, it automatically updates anything that uses it.

If you are familiar with RxJS, this might remind you of BehaviorSubject or, more generally, multicasted values. However, unlike BehaviorSubject, Signals would not require the Observers to subscribe to be notified of changes.

With Signals, Subscriptions get created and destroyed automatically under the hood. More or less what happens using the async pipe in RxJS. However, unlike Observables, Signals don’t require a Subscription to be used outside the template.

Signals go to great lengths to hide some of the complexities of RxJS.

As said above, Signals contain values that change over time. So, let’s have a look at that.

Signals In Angular — Example

Here you can find a clean example of how Signals work (Signals Example).

Next, I'll show a possible implementation in Angular.
Be aware that if you want to use Signals in Angular, you should use Angular v16.0.0-next.0 which has just been released.

Needless to say, it is still a prototype and you may not want to use it in production:)

Another way to try it out is by using StackBlitz and importing the signal folder.

Here is what Signals in Angular could look like:

...

@Component({
  selector: 'signals-not-noise',
  standalone: true,
  template: `
    <div>Count: {{ count() }}</div>
    <div>Double: {{ doubledCount() }}</div>
  `
})
export class App {
  count = signal(0);
  doubledCount = computed(() => this.count() * 2);

  constructor() {
    setInterval(() => this.count.set(this.count() + 1), 1000);
  }
}
Enter fullscreen mode Exit fullscreen mode

Since doubleCount uses count that is a Signal, doubleCount gets updated every time count changes.

In other words, doubleCount depends on, or is computed from, count and this dependency is reflected automatically whenever the latter changes.

Thanks to computed we can take the value of other Signals and build on them. Moreover, it is memorized, so it doesn’t need to run the computation every time you need the value, but only when it changes.

This leads to fine-grained reactivity that could support better change detection.

What about that function call in the template? Function calls in templates are not as bad as you might thing.

Signals and RxJS

It might seem Signals is going to take over and replace RxJS.

However, Signals don’t handle race conditions very well, so RxJS is going to stay and support asynchronous operations.

It is also possible to turn SIgnals into Observables and vice versa.

You can watch an explanation by Joshua Morony.

Using Signals in Angular might facilitate learning Angular, at least in the beginning.

New Change Detection

This could be a big change for Angular.

Thanks to Signals, we can see a future without zone.js.

Signals allow checking changes at a more granular level rather than checking the whole component tree for changes. In turn, this could be used to improve Angular change detection.

At the moment, different frameworks check what changes in the DOM tree at different levels, for example at

App tree level — Angular
Component tree level — React
Individual elements — Solid
It seems like Angular aims at becoming more granular, and in doing so, they plan to keep Signals interoperable with zone.js.

According to Alex Rickabaugh (the same person behind The Little-known Story Behind Angular Standalone Components and Technical Lead in the Angular Core Team), you wouldn’t need ngOnChange in a Signal world.

Good stuff

Top comments (0)