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: Signals const count = signal(0); 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. setTimeout By the way, my name is Tom Smykowski, I’m an expert in building scalable, enterprise Angular applications, and in this series, I’ll be teaching you how to do it! By the way, my name is Tom Smykowski, I’m an expert in building scalable, enterprise Angular applications, and in this series, I’ll be teaching you how to do it! Tom Smykowski Tom Smykowski 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. OnPush ngOnChanges Observables Subjects 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. memory leaks Subject BehaviourSubject fromEvent 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: Signals 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. 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. signal 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: signals The toSignal function allows you to turn an Observable to signal: toSignal 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});
} 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. counterObservable initialValue 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: toSignal The subscription created by toSignal automatically unsubscribes from the given Observable when the component or service which calls toSignal is destroyed. The subscription created by toSignal toSignal 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. manualCleanup 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. signals 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 free here. 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 free here. free here free here If you have any questions, ask them in the comment section!

effect

scale

Use This Checklist to Make Your Angular App Scalable

Angular Signals Are A Game Changer: How They're A Great Fit For Scalable Apps

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Angular Destroys React When It Comes to Scaling Enterprise Apps: Here's Why

10 Useful JavaScript Functions to Learn

10 Cool Angular Material Admin Dashboard Templates

13 Angular App Optimization Tips for Frontend Developers

25 Stories To Learn About Angularjs

16 JavaScript Protips [2020 Edition]

Angular Destroys React When It Comes to Scaling Enterprise Apps: Here's Why

10 Useful JavaScript Functions to Learn

10 Cool Angular Material Admin Dashboard Templates

13 Angular App Optimization Tips for Frontend Developers

25 Stories To Learn About Angularjs

16 JavaScript Protips [2020 Edition]

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps