Angular Signals: Best practices around exposing Signals

Some best practices are emerging as Signals are available in developer preview with Angular 16.

As a reminder, this is how we create a Signal with Angular:

currency = signal('USD');

This creates a WritableSignal, meaning that any code that has a reference to that Signal can update its value with:

currency.set('CAD');

While being able to update a Signal from anywhere can be convenient, it can also lead to components taking over too much of the business logic of an application. With Angular, we want to delegate that part to services, which is why when using RxJs Subjects, we got into the habit of exposing them as read-only Observables:

private currencySubject = new BehaviorSubject('USD');
  
 getCurrency$(): Observable<string> {
    return this.currencySubject.asObservable();
 }

We can apply the same idea to Signals because the Angular team conveniently included a method to return a Signal as read-only:

 private currencySignal = signal('USD');

 getCurrencySignal(): Signal<string> {
   return this.currencySignal.asReadonly();
 }

While the above code works well, there is a downside to it. To read the value of a Signal, we have to call it as a function. This means that the above public Signal could be called like this in a component template:

My signal value is: {{ getCurrencySignal()() }}

The double-parentheses are not ideal.

Instead, we can use the getter syntax to expose our Signal as a public class property:

private currencySignal = signal('USD');

get currency(): Signal<string> {
   return this.currencySignal.asReadonly();
}

And our HTML template becomes:

My signal value is: {{ currency() }}

Many of you think: “We’re calling a method in a template; that’s an Angular anti-pattern!” And you would be right under normal circumstances, but Signals are different.

One of the main goals of Angular Signals is to improve how change detection works within the Angular framework. As a result, Signal-based components will work differently and only get re-rendered when the Signals used by such components get updated.

As a result, it won’t cost anything anymore to call methods in the templates of signal-based components. Not only that, these components will be faster and wiser when it comes down to pinpointing accurate change detection of specific views and components.

To learn more about Signals, check out my continuously updated course here.

My name is Alain Chautard. I am a Google Developer Expert in Angular, as well as a consultant and trainer at Angular Training where I help web development teams learn and become comfortable with Angular.

If you need any help with web development, feel free to get in touch!

If you enjoyed this article, please clap for it or share it. Your help is always appreciated. You can also subscribe to my articles here, and subscribe to my Daily Angular Newsletter to receive useful daily tips.