6 Signals: A new approach to reactive programming

In the previous chapter, we talked about reactive programming, how it is useful when working with frontend 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 problems that RxJS itself has that 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 us 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 problems with reactivity.

6.1 Why go beyond RxJS?

Previously, we described RxJS as a powerful, flexible, and very capable library for working with reactivity-related logic. So if this library is so mighty, why do we need to introduce another approach? It turns out the vast capabilities of RxJS might actually be a part of the problem in this case. Let’s see what the problems are and then discuss the solutions.

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