{"id":2829,"date":"2024-04-11T09:03:44","date_gmt":"2024-04-11T07:03:44","guid":{"rendered":"https:\/\/www.thecodecampus.de\/blog\/?p=2829"},"modified":"2025-04-17T13:15:52","modified_gmt":"2025-04-17T11:15:52","slug":"how-to-combine-angular-signals-and-rxjs","status":"publish","type":"post","link":"https:\/\/www.thecodecampus.de\/blog\/how-to-combine-angular-signals-and-rxjs\/","title":{"rendered":"Angular Signals Part 2 – How to combine Angular Signals and RxJS"},"content":{"rendered":"

Klicke hier<\/a> f\u00fcr die deutsche Version des Blog-Posts.<\/em><\/strong><\/p>\n

Angular 17: Signals + RxJS = Perfect Match<\/h2>\n

In the first article of this series, Angular Signals Part 1 – How-to guide on Angular Signals<\/a>, we summarized what Angular Signals are and how to use them. Now let’s take a look at why Signals are not a replacement for RxJS and how to best combine both technologies.<\/p>\n

\"Angular<\/a><\/p>\n

As already mentioned, Signals are particularly well suited to managing synchronous states in the application. However, this means that they take over a task that was previously handled by RxJS. So the question is whether Signals will completely replace RxJS?<\/p>\n

The answer is: No.<\/p>\n

To understand why RxJS does not become less important with the use of Signals, you need to know the application purposes of the technologies and their strengths and weaknesses. This is exactly what we will do in this article.<\/p>\n

Strengths and weaknesses of the technologies<\/h2>\n

To choose the right technology for the right application, you need to know about its advantages and disadvantages. Next, we will look at the strengths and weaknesses of Signals and RxJS.<\/p>\n

RxJS<\/h3>\n

The following section is of course not a complete analysis or introduction to RxJS. It is only intended to provide an overview so that an assessment and differentiation can be made regarding Angular Signals. If you would like to know more about RxJS, you can take a look at its documentation here<\/a>.<\/p>\n

There are two areas that RxJS covers. One is the management and coordination of asynchronous events, the other is reactive programming. With the observable pattern, RxJS can efficiently handle asynchronous events and operations as data streams.<\/p>\n

The large number of operators, such as map<\/code> or filter<\/code>, which are available for processing and converting observables, is a great strength of RxJS. This allows complex tasks, such as coordinating multiple events or combining data streams, to be solved in a simple and readable way. Observables also allow us to handle and process HTTP events such as success, error and completion. With the HTTP client, Angular even provides us with a service that allows us to work directly with observables. In contrast to working with promises in JavaScript.<\/p>\n

RxJS, with libraries like Tydux<\/a> and NgRx<\/a>, has been the go-to for global state management so far. At this point, signals can now make our lives much easier.<\/p>\n

Angular Signals<\/h3>\n

In contrast to RxJS, Signals have limited functionality when it comes to reacting to events. Since you can only use the effect()<\/code> and computed()<\/code> function to react to changes and do not have as many and extensive operators at hand, more complex tasks in particular can lead to a lot of unreadable code. Signals do not have classic and well-known operators such as catchError<\/code> or switchMap<\/code>, which are responsible for canceling requests at a certain point in time when a new request with new data arrives.<\/p>\n

Signals do not aim to replace RxJS entirely, but to simplify reactive programming.
\nA good example are the following code blocks, which both represent the same functionality. If the variables firstName<\/code> or lastName<\/code> change, the variable fullName<\/code> should be updated.<\/p>\n

The first block shows how RxJS solves this task with the fullName$<\/code> observable. We use combineLatest<\/code> to create a new observable that combines our two observable sources. We must remember that combineLatest<\/code> only produces values if both firstName$<\/code> and lastName$<\/code> have returned a value at least once. To use the actual value of fullName$<\/code>, we need to subscribe to the observable. Then we also have to take care of terminating the subscription.<\/p>\n

\n
public fullName: string | null = null \r\npublic fullName$ = combineLatest([this.firstName$, this.lastName$]).pipe( \r\n  map(([firstName, lastName]) =>`${firstName} ${lastName}`), \r\n);\r\n\r\n\/\/ Usage with subscription and takeUntilDestroyed operator \r\nfullName$ \r\n  .pipe(takeUntilDestroyed()) \r\n  .subscribe(fullName => this.fullName = fullName)\r\n<\/pre>\n<\/div>\n
With signals, using the computed()<\/code> function, the whole thing looks different. We access the value of a signal by using the round brackets. In the computed()<\/code> function, the dependencies on the content of the signals firstName<\/code> and lastName<\/code> are automatically recorded, just because we have used their content. We also no longer need to manage subscriptions. And last but not least, signals always have an initial value when they are created.<\/p>\n
\n
fullName = computed(() => { \r\n  return`${this.firstName()} ${this.lastName()}`; \r\n}); \r\n\r\n\/\/ Usage with () \r\nfullName()<\/pre>\n<\/div>\n
RxJS is a powerful and versatile tool with many powerful operators. We need to understand the behavior of the individual operators in order to be able to work safely with RxJS. In addition, we have to take care of the creation and combination of observables and their subscriptions. Signals, on the other hand, are simpler to use. We do not need to manage subscriptions and dependencies. However, the execution of Signals is synchronous and can therefore only replace the synchronous parts of RxJs and simplify programming and state management.<\/p>\n
\n\"Angular\n<\/picture>\n<\/a><\/p>\n
How to combine the two approaches?<\/h2>\n
Now that we have established that RxJS is still important and relevant, the question remains of how to use the two technologies together. In principle, exactly as we stated above. Signals are used for synchronous operations, such as state management, and all asynchronous operations, such as events and queries to the database, are handled with RxJS.<\/p>\n
There are two functions that ensure that this interaction works smoothly.<\/p>\n
toSignal()<\/h3>\n
The toSignal()<\/code> function can be used to generate a readonly signal that tracks the value of an observable.
\nIn our example, we have an observable movies$<\/code>, which is waiting for the response of an HTTP request, in our case a list of movies. The Signal movies<\/code> is linked to movies$<\/code> with toSignal()<\/code> and as soon as the response is there and the observable outputs the movies received, the movies<\/code> Signal is also updated.<\/p>\n
\n
private movies$ = this.http.get<MovieResponse>(this.url).pipe(\r\n  map((data) =>\r\n    data.results.map((m) => ({...m}) as Movie),\r\n  ),\r\n  shareReplay(1),\r\n);\r\n\r\nmovies = toSignal(this.movies$);<\/pre>\n<\/div>\n
We can then use this Signal in the template to display the movies. This means that we no longer need an async pipe in the template.<\/p>\n
toSignal()<\/code> subscribes by itself to the corresponding observable and also unsubscribes automatically if the component or service in which the call was made is destroyed.<\/p>\n
However, there is one more thing to watch out for. Since toSignal()<\/code> immediately subscribes to the observable, various side effects can occur. For example, if an HTTP request is attached to the observable, this call is executed immediately, regardless of whether there is currently a component that wants the data. This can be particularly difficult in shared services.
\nMemory leaks are also something to keep in mind. toSignal()<\/code> can only be called in an injection context or with an injector. This means that if the injector, and the associated Signal, exist beyond the lifecycle of the component, memory leaks may occur. This is particularly the case if toSignal()<\/code> is called in root services or root components.<\/p>\n
toObservable()<\/h3>\n
In contrast to toSignal()<\/code>, toObservable()<\/code> is used to create an observable that tracks the value of a Signal. This allows you to trigger another HTTP request, for example, and reload further data.
\nIn our example, we have a Signal selectedMovie<\/code> that saves the movie that the user has just clicked on. With toObservable()<\/code> we can react every time selectedMovie<\/code> changes and make another HTTP request in the observable pipeline to retrieve the characters of the movie. We then intercept the corresponding response with the movieCharacters$<\/code> observable.<\/p>\n
\n
selectedMovie = signal<Movie | undefined>(undefined);\r\n\r\nprivate movieCharacters$ = toObservable(this.selectedMovie).pipe(\r\n  \/\/... See the complete code in the StackBlitz below\r\n  this.http.get<Character>(characterUrl))),\r\n  ),\r\n);<\/pre>\n<\/div>\n
This allows us to react to synchronous state changes with asynchronous operations. The movieCharacter$<\/code> observable can now also be made available again with a signal for templates.
\nWith the toSignal()<\/code> and toObservable()<\/code> function, asynchronous processes can be handled and encapsulated very well in the service. Only signals that are used for synchronous state management are then accessible to the outside.<\/p>\n
ngxtension<\/h2>\n
ngxtension<\/a> is a library with utility functions for Angular, which are intended to make development with Angular more convenient. There are already more than ten functions that make working with Signals easier. We would now like to introduce two of these functions that we find the most practical.<\/p>\n
toLazySignal()<\/h3>\n
The toLazySignal()<\/a> function works in a similar way to the original toSignal()<\/code> function, with the exception that a subscription is not generated immediately. toLazySignal()<\/code> therefore comes into play exactly where we saw a problem with toSignal()<\/code> above. Only when the signal is read for the first time does Angular subscribe to the corresponding observable.<\/p>\n
const people = toSignal(this.people$);\r\n\r\nconst planets = toLazySignal(this.planets$);<\/pre>\n
You can see from this code snippet that the functions are used in exactly the same way. In the embedded StackBlitz project, we have also compared the two functions in a component so that you can try out the subscriptions for yourself.<\/p>\n
connect()<\/h3>\n
The connect()<\/a> function links a signal with an observable. This doesn’t sound any different from the toSignal()<\/code> function, but while toSignal()<\/code> only returns a readonly signal, connect()<\/code> returns a writeable signal.<\/p>\n
So if you want to set the value of a signal based on an observable, you can do this as shown in the following example:<\/p>\n
\n
connect(this.signalName, this.connectForm.valueChanges);<\/pre>\n<\/div>\n
The Signal signalName<\/code> is linked to the valueChanges<\/code> observable of the FormControl. Whenever the form is updated because the entered value is changed, the Signal is also updated.<\/p>\n
However, connect()<\/code> does not only have this one application purpose. It is also possible to connect two Signals with each other, whereby a writeable Signal is obtained again, and connect()<\/code> also makes it possible to connect any number of streams with just one Signal. There are therefore a large number of use cases where the connect()<\/code> function makes your work easier.<\/p>\n
Experience is the best teacher: Hands-On with Signals and RxJS<\/h2>\n
Are you ready to put theory into practice? In this interactive StackBlitz example, we’ve created a sample application that takes the basic concepts of RxJS and Signals and includes all the examples and features presented. Dive in and experiment to see Signals and RxJS in action!<\/p>\n