6 Signals: a new approach to reactive programming

In the previous chapter we talked about reactive programming, how it is useful when working with front-end applications, and how Angular’s commonly chosen library to work with reactivity is RxJS. We covered new approaches and tools Angular provides for working with RxJS, but we did not cover the issues that RxJS itself has, and which cannot be mitigated simply by adding new tools into the arsenal of Angular developers. In this chapter, let’s focus on these new changes, and discuss signals: a new reactive primitive introduced by the Angular core team into the framework itself, which allows to read values, subscribe to them, derive new values, and execute side effects without having to deal with RxJS at all. Let us see why this new primitive will be helpful and allow us to mitigate various issues with reactivity.

6.1 Why go beyond RxJS?

6.1.1 What are the problems with RxJS?

6.1.2 What must the solution look like?

6.2 What is a signal?

6.2.1 Creating signals

6.2.2 Updating signals

6.2.3 Creating Signals vs Observables

6.3 Building Angular components with signals

6.3.1 Creating TimeOffComponent

6.3.2 Handling signals in Angular components

6.4 Computed signals

6.4.1 Creating computed signals

6.4.2 Simplifying complex logic in Angular components using computed signals

6.5 Effects

6.5.1 Creating effects

6.5.2 Important things to know about effects

6.5.3 When to use effects

6.6 RxJS and signals interoperability

6.6.1 Converting Observables to signals

6.6.2 Converting signals to Observables

6.7 Exercises for the reader

6.8 Summary