Signals and RxJS

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

Table of Contents
Previous LessonRxJS HistoryNext LessonApplication setup
  • |

Lesson Transcript

  • [00:00 - 00:04] This is an interesting topic. In this lesson, we are going to explore signals and RxJS.

  • [00:05 - 00:12] When Angular released signals, there were a lot of debates on will signals replace RxJS? Will signals be compatible with RxJS?

  • [00:13 - 00:19] Will RxJS still be dominant, and signals won't be used at all? So, a lot of talk, a lot of debate.

  • [00:20 - 00:24] Now, I read the whole RFC Angular signals. I will leave the link down below if you want to read it as well.

  • [00:25 - 00:28] In here, I will summarize everything that I've read in there. So why signals?

  • [00:29 - 00:33] Signals are a new reactive primitive in Angular. But what is reactive?

  • [00:34 - 00:49] Reactive, is when the UI updates based on the data models that have changed. So, in order to get this reactive feeling that the UI always reacts to any update or change, signals were introduced. But, didn't we already have reactivity in Angular?

  • [00:50 - 00:55] Yes, we have reactivity in Angular. It uses zone.js under the hood.

  • [00:56 - 00:59] This is a library. But the problem is zone.js is not scalable.

  • [01:00 - 01:09] That's why the Angular team decided to introduce a new reactive primitive. But wait, why are RxJS observables are not used as the reactive primitive in Angular?

  • [01:10 - 01:14] Because everything in Angular is built on top of RxJS observables. That's a very good question.

  • [01:15 - 01:33] The Angular team gave us a detailed explanation why they have chosen not to use RxJS observables as the reactive primitive. This is a short summary if you are interested to read and look at the examples that they have provided, you can read the RFC, I will link it down below.

  • [01:34 - 01:39] But basically, RxJS observables have their limitations. They have some glitches.

  • [01:40 - 01:50] Please bear in mind this is only about template rendering and not about handling events. RxJS observables are amazing for orchestrating complex and synchronous operations.

  • [01:51 - 01:58] That's why the Angular team decided to introduce a new reactive primitive. So what does it mean a new reactive primitive?

  • [01:59 - 02:02] What changes are we expected to have? Some internal APIs will change.

  • [02:03 - 02:09] APIs like form validation. APIs that actually change the state of the UI.

  • [02:10 - 02:20] Other APIs will still use RxJS observables under the hood. For example, HttpClient EventEmitter, those won't change at all because it also doesn't make sense to change them.

  • [02:21 - 02:28] They are only used for events and not for the UI updates. Another important thing is RxJS becomes optional.

  • [02:29 - 02:40] The Angular team has decided to make signals the default go to solution for simple reactivity. Once you need to handle more complex scenarios, you should use RxJS instead.

  • [02:41 - 02:51] Also, the Angular team doesn't want to make RxJS the default best practice. So they're opting for the teams to have a choice in whether they want to use RxJS or not.

  • [02:52 - 03:09] And the last thing is RxJS is considered quite complex, by making this optional the entry barrier into the Angular framework becomes much easier. This was actually a big pain point for new guys starting with the Angular framework because RxJS was just too complex.

  • [03:10 - 03:21] Another great thing is the Angular team decided to make observables and signal interoperable. This means that you can convert a signal to an observable and an observable to a signal.

  • [03:22 - 03:29] Now, to summarize everything in a couple of sentences, I will say it in Layman's terms. Use signals for state, use observables for events.

This is an interesting topic. In this lesson, we are going to explore signals and RxJS. When Angular released signals, there were a lot of debates on will signals replace RxJS? Will signals be compatible with RxJS? Will RxJS still be dominant, and signals won't be used at all? So, a lot of talk, a lot of debate. Now, I read the whole RFC Angular signals. I will leave the link down below if you want to read it as well. In here, I will summarize everything that I've read in there. So why signals? Signals are a new reactive primitive in Angular. But what is reactive? Reactive, is when the UI updates based on the data models that have changed. So, in order to get this reactive feeling that the UI always reacts to any update or change, signals were introduced. But, didn't we already have reactivity in Angular? Yes, we have reactivity in Angular. It uses zone.js under the hood. This is a library. But the problem is zone.js is not scalable. That's why the Angular team decided to introduce a new reactive primitive. But wait, why are RxJS observables are not used as the reactive primitive in Angular? Because everything in Angular is built on top of RxJS observables. That's a very good question. The Angular team gave us a detailed explanation why they have chosen not to use RxJS observables as the reactive primitive. This is a short summary if you are interested to read and look at the examples that they have provided, you can read the RFC, I will link it down below. But basically, RxJS observables have their limitations. They have some glitches. Please bear in mind this is only about template rendering and not about handling events. RxJS observables are amazing for orchestrating complex and synchronous operations. That's why the Angular team decided to introduce a new reactive primitive. So what does it mean a new reactive primitive? What changes are we expected to have? Some internal APIs will change. APIs like form validation. APIs that actually change the state of the UI. Other APIs will still use RxJS observables under the hood. For example, HttpClient EventEmitter, those won't change at all because it also doesn't make sense to change them. They are only used for events and not for the UI updates. Another important thing is RxJS becomes optional. The Angular team has decided to make signals the default go to solution for simple reactivity. Once you need to handle more complex scenarios, you should use RxJS instead. Also, the Angular team doesn't want to make RxJS the default best practice. So they're opting for the teams to have a choice in whether they want to use RxJS or not. And the last thing is RxJS is considered quite complex, by making this optional the entry barrier into the Angular framework becomes much easier. This was actually a big pain point for new guys starting with the Angular framework because RxJS was just too complex. Another great thing is the Angular team decided to make observables and signal interoperable. This means that you can convert a signal to an observable and an observable to a signal. Now, to summarize everything in a couple of sentences, I will say it in Layman's terms. Use signals for state, use observables for events.