Signals in Angular are quite a new concept, so not everyone is using them nor is familiar with them. Creating a signal is quite easy:
const count = signal(0);
But what it really is? Well, it’s a construct that plays very well with reactive programming and Angular templates. Because so far Angular has had to do a lot of things to recognize what changes and when to update templates. Just to say zone.js is a really huge part of Angular, and it tries to tap into natural things like setTimeout functions to spy on stuff coders do to update things smoothly.
By the way, my name is
The OnPush method changed it because with this strategy, Angular reacts only to input changes and events. However, it’s not a perfect solution, and having to choose between ngOnChanges, get/setters for inputs, and Observables and Subjects isn’t really fun. All of these approaches come with more or less boilerplate that only obfuscates the feature-oriented components.
What’s even more important when working with asynchronicity in Angular is that it’s really easy to introduce memory leaks. All you have to do is not unsubscribe from a Subject (or BehaviourSubject etc.) or event-based observables (like fromEvent) for them to live not-quite rent-free forever in the device memory. It’s considerably the biggest drawback of these approaches.
Not a lot is said about it, but Angular Signals are also a solution to this problem. Specifically, as we can read in Angular documentation:
When you create an effect, it is automatically destroyed when its enclosing context is destroyed. This means that effects created within components are destroyed when the component is destroyed. The same goes for effects within directives, services, etc.
So, we don’t have to worry about this. Context knows about signals, and destroys them properly. So if you have a signal in your service or component, you don’t have to worry about a memory leak.
Moreover, and this is really impressive, is how signals handle Observables and RxJS. No doubt, signals, as of today, aren’t able to take over all the good RxJS gives, however, in some cases, we may not need RxJS when working with signals.
But what it means is that we could still be at risk of creating memory leaks when integrating signals and RxJS. The good news is that the unique construction of signals addresses this problem:
The toSignal function allows you to turn an Observable to signal:
import { Component } from '@angular/core';
import { AsyncPipe } from '@angular/common';
import { interval } from 'rxjs';
import { toSignal } from '@angular/core/rxjs-interop';
@Component({
template: `{{ counter() }}`,
})
export class Ticker {
counterObservable = interval(1000);
// Get a `Signal` representing the `counterObservable`'s value.
counter = toSignal(this.counterObservable, {initialValue: 0});
}
As we can see in this example provided by Angular documentation, counter becomes a signal tracking counterObservable. Because a standard observable doesn’t guarantee to emit a value, we set an initialValue, otherwise, it would be undefined.
This is, however, not the important part of the story, because the important one is that toSignal takes care of unsubscribing from the observable:
The subscription created by toSignal automatically unsubscribes from the given Observable when the component or service which calls toSignal is destroyed.
Basically meaning that it acts as a memory leak sanitizer, making sure that observables we use in components and services won’t create memory leaks because unsubscription is taken care automatically of.
It’s a considerable advantage of signals contributing to solving the major cause of lags of Angular apps. Since toSignal unsubscribes automatically when a service or component is destroyed, there’s no risk of human error.
What’s great? Of course, there are cases where memory leaks can still happen, and for those cases, we still can clear resources manually with manualCleanup which is called when the signal would normally do house chores.
From the perspective of building scalable Angular apps for this, and other reasons, I’ll write in the following articles, that signals are great for preserving resources, increasing the responsiveness of Angular apps, and saving resources, especially in apps that by themselves use a lot of these.
The streamlined handling of reactivity Angular 16 introduced with gradual feature build-up (like signal-based inputs in Angular 19) makes them a great fit for scalable apps due to lower maintenance costs, lower risk of memory leaks, and better overall performance. I recommend to gradually rewrite your app to signals if you want to scale it smoothly.
I’ve prepared a free checklist on how to make your Angular app scalable and ready for enterprise demand. If you’re interested, you can get this checklist for
If you have any questions, ask them in the comment section!
