{"id":2793,"date":"2024-04-11T09:01:11","date_gmt":"2024-04-11T07:01:11","guid":{"rendered":"https:\/\/www.thecodecampus.de\/blog\/?p=2793"},"modified":"2026-04-09T11:25:26","modified_gmt":"2026-04-09T09:25:26","slug":"wie-kombiniert-man-angular-signals-und-rxjs","status":"publish","type":"post","link":"https:\/\/www.thecodecampus.de\/blog\/wie-kombiniert-man-angular-signals-und-rxjs\/","title":{"rendered":"Angular Signals Teil 2 – Wie kombiniert man Angular Signals und RxJS"},"content":{"rendered":"

Go here<\/a> for the english version of this blog post.<\/em><\/strong><\/p>\n

Angular 17: Signals + RxJS = Perfekte Erg\u00e4nzung<\/h2>\n

Im ersten Beitrag dieser Artikelserie, Angular Signals Teil 1 – How-to Guide f\u00fcr Angular Signals<\/a>, haben wir zusammengefasst was Angular Signals sind und wie man sie verwendet. Jetzt wollen wir uns anschauen warum Signals kein Ersatz f\u00fcr RxJS sind und wie man beide Technologien am besten kombiniert.<\/p>\n

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

Wie bereits festgehalten, sind Signals besonders gut daf\u00fcr geeignet synchrone Zust\u00e4nde in der Anwendung zu verwalten. Damit \u00fcbernehmen sie aber eine Aufgabe die bisher von RxJS behandelt wurde. Die Frage ist also, ob Signals RxJS g\u00e4nzlich abl\u00f6sen werden?<\/p>\n

Die Antwort darauf ist: Nein.<\/p>\n

Um zu verstehen, warum RxJS mit der Verwendung von Signals nicht weniger wichtig wird, muss man die Anwendungszwecke der Technologien und ihre St\u00e4rken und Schw\u00e4chen kennen. Genau dies, werden wir in diesem Beitrag machen.<\/p>\n

Im Folgenden Blog erf\u00e4hrst Du wie Du Angular Signals und RxJS zusammen verwendest.<\/p>\n

St\u00e4rken und Schw\u00e4chen der Technologien<\/h2>\n

Um die passende Technologie f\u00fcr den entsprechenden Anwendungszweck zu w\u00e4hlen, muss man \u00fcber ihre Vor- und Nachteile Bescheid wissen. Welche St\u00e4rken und Schw\u00e4chen Signals und RxJS haben schauen wir uns als n\u00e4chstes an.<\/p>\n

RxJS<\/h3>\n

Der folgende Abschnitt ist nat\u00fcrlich keine vollst\u00e4ndige Analyse oder Einf\u00fchrung zu RxJS. Er soll nur einen \u00dcberblick geben, damit eine Einsch\u00e4tzung und Abgrenzung bez\u00fcglich Angular Signals gemacht werden kann. Wenn Du noch mehr \u00fcber RxJS wissen m\u00f6chtest kannst du hier<\/a> einen Blick in ihre Dokumentation werfen.<\/p>\n

Es gibt zwei Aufgabenbereiche die RxJS abdeckt. Zum einen die Verwaltung und Koordination von asynchronen Events, zum anderen die reaktive Programmierung. Mit dem Observable-Pattern kann RxJS effizient asynchrone Events und Operationen, als Datenstr\u00f6me handhaben.<\/p>\n

Die Vielzahl von Operatoren, wie map<\/code> oder filter<\/code>, die zur Verarbeitung und Umwandlung der Observables zur Verf\u00fcgung stehen, ist eine gro\u00dfe St\u00e4rke von RxJS. Dadurch k\u00f6nnen komplexe Aufgaben, z.B. das Koordinieren von mehreren Ereignissen oder das Kombinieren von Datenstr\u00f6men, simpel und leserlich gel\u00f6st werden. Mit dem HTTP-Client bekommen wir in Angular einen Service zur Verf\u00fcgung gestellt, der uns direkt eine Arbeit mit Observables erm\u00f6glicht. Observables erm\u00f6glichen es uns die HTTP-Ereignisse, wie success, error und completion, zu behandeln und zu verarbeiten.<\/p>\n

RxJS war, mit Bibliotheken wie Tydux<\/a> oder NgRx<\/a>, das bisherige Go-To f\u00fcr globales State Management. An diesem Punkt k\u00f6nnen uns nun Signals das Leben deutlich erleichtern.<\/p>\n

Angular Signals<\/h3>\n

Im Gegensatz zu RxJS haben Signals eine eingeschr\u00e4nkte Funktionalit\u00e4t, was das Reagieren auf Events angeht. Da man nur die effect()<\/code> und computed()<\/code> Funktionen nutzen kann, um auf \u00c4nderungen in anderen Signals zu reagieren, und nicht so viele und umfangreiche Operatoren zur Hand hat, k\u00f6nnen gerade komplexere Aufgaben zu viel und unleserlichem Code f\u00fchren. Signals haben beispielsweise keine klassischen und bekannten Operatoren wie catchError<\/code> oder switchMap<\/code>, die daf\u00fcr zust\u00e4ndig sind, Anfragen zu einem bestimmten Zeitpunkt abzubrechen, wenn eine neue Anfrage mit neuen Daten kommt.<\/p>\n

Signals zielen nicht darauf ab RxJS g\u00e4nzlich zu ersetzen, sondern die reaktive Programmierung zu vereinfachen.
\nEin gutes Beispiel sind die folgenden Code-Bl\u00f6cke, die beide die gleiche Funktionalit\u00e4t darstellen. Wenn sich die Variablen firstName<\/code> oder lastName<\/code> \u00e4ndern, soll die Variable fullName<\/code> aktualisiert werden.<\/p>\n

Der erste Block zeigt wie RxJS diese Aufgabe mit dem fullName$<\/code> Observable l\u00f6st. Wir erzeugen mit combineLatest<\/code> ein neues Observable, dass unsere beiden Observable Quellen kombiniert. Dabei m\u00fcssen wir daran denken, dass combineLatest<\/code> erst Werte produziert, wenn sowohl firstName$<\/code> und lastName$<\/code> mindestens einmal einen Wert geliefert haben. Zur Verwendung des eigentlichen Wertes von fullName$<\/code> m\u00fcssen wir an dem Observable subscriben. Dann m\u00fcssen wir uns auch \u00fcber das Beenden der Subscription k\u00fcmmern.<\/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\/\/ Verwendung mit Subscription und takeUntilDestroyed Operator\r\nfullName$\r\n  .pipe(takeUntilDestroyed())\r\n  .subscribe(fullName => this.fullName = fullName)<\/pre>\n<\/div>\n
Mit Signals, unter Verwendung der computed()<\/code> Funktion, sieht das Ganze anders aus. Auf den Wert eines Signals greifen wir mit der Verwendung der runden Klammern zu. In der computed()<\/code> Funktion werden die Abh\u00e4ngigkeiten an den Inhalt der Signals firstName<\/code> und lastName<\/code> automatisch erfasst, nur dadurch, dass wir deren Inhalte verwendet haben. Auch m\u00fcssen wir keine Subscription mehr verwalten. Und zu guter Letzt haben Signals immer einen initialen Wert bei ihrer Erzeugung.<\/p>\n
\n
fullName = computed(() => {\r\n  return`${this.firstName()} ${this.lastName()}`;\r\n});\r\n\r\n\/\/ Verwendung mit ()\r\nfullName()<\/pre>\n<\/div>\n
RxJS ist ein leistungsf\u00e4higes und vielseitiges Werkzeug, mit vielen m\u00e4chtigen Operatoren. Uns muss das Verhalten der einzelnen Operatoren klar sein, um sicher mit RxJS arbeiten zu k\u00f6nnen. Zus\u00e4tzlich m\u00fcssen wir uns um das Erzeugen und Kombinieren von Observables und deren Subscriptions k\u00fcmmern. Signals auf der anderen Seite sind simpler in der Verwendung. Wir brauchen keine Subscriptions und Abh\u00e4ngigkeiten zu managen. Die Ausf\u00fchrung von Signals ist allerdings synchron und kann daher nur die synchronen Teile von RxJs ersetzen und dabei das Programmieren und das State Management vereinfachen.<\/p>\n
\n<\/picture>\n<\/picture>\n\"Angular<\/picture>\n<\/a><\/p>\n
Wie kombiniert man die beiden Ans\u00e4tze?<\/h2>\n
Da wir nun festgehalten haben, dass RxJS weiterhin wichtig und relevant ist, bleibt die Frage wie man die beiden Technologien zusammen verwendet. Im Prinzip genau so wie wir es oben festgehalten haben. F\u00fcr synchrone Vorg\u00e4nge, wie das State Management, verwendet man Signals und alle asynchronen Operationen, wie Events und Anfragen an die Datenbank, sollten mit RxJS behandelt werden.<\/p>\n
Es gibt zwei Funktionen, die daf\u00fcr sorgen, dass genau dieses Zusammenspiel reibungslos funktioniert.<\/p>\n
toSignal()<\/h3>\n
Mit der toSignal()<\/code> Funktion kann man ein readonly Signal erzeugen, dass den Wert eines Observables verfolgt.
\nIn unserem Beispiel haben wir ein Observable movies$<\/code>, welches auf die Antwort eines HTTP-Requests wartet, in unserem Fall eine Liste von Filmen. Das Signal movies<\/code> wird mit toSignal()<\/code> an movies$<\/code> gekn\u00fcpft und sobald die Antwort da ist, und das Observable die erhaltenen Filme ausgibt, aktualisiert sich auch das movies<\/code> Signal.<\/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
Dieses Signal k\u00f6nnen wir dann im Template benutzen um die Filme anzuzeigen. Dadurch brauchen wir im Template auch keine async pipe mehr.<\/p>\n
toSignal()<\/code> subscribed also von selbst an das entsprechende Observable und unsubscribed auch automatisch, wenn die Komponente oder der Service in der der Aufruf gemacht wurde zerst\u00f6rt wird.<\/p>\n
Bei einer Sache muss man aber noch aufpassen. Da toSignal()<\/code> sofort an das Observable subscribed, kann es zu verschiedenen Seiteneffekten kommen. Wenn an dem Observable z.B. ein HTTP-Request h\u00e4ngt, wird dieser Aufruf sofort ausgef\u00fchrt, unabh\u00e4ngig davon, ob es gerade eine Komponente gibt die die Daten haben m\u00f6chte. Dies kann besonders in Shared Services schwierig sein.
\nSpeicherlecks (Memory Leaks) sind ebenfalls etwas, das man im Hinterkopf behalten sollte. toSignal()<\/code> kann nur in einem Injection Kontext oder mit einem Injector aufgerufen werden. Das hei\u00dft, wenn der Injector, und das damit verkn\u00fcpfte Signal, \u00fcber den Lebenszyklus der Komponente hinaus existieren, kann es zu Speicherlecks kommen. Insbesondere dann, wenn toSignal()<\/code> in root Services oder root Komponenten aufgerufen wird.<\/p>\n
toObservable()<\/h3>\n
Umgekehrt zu toSignal()<\/code> erzeugt man mit toObservable()<\/code> ein Observable, dass den Wert eines Signals verfolgt. Dadurch kann man z.B. einen weiteren HTTP-Request ausl\u00f6sen und weitere Daten nachladen.
\nIn unserem Beispiel haben wir ein Signal selectedMovie<\/code>, dass den Film speichert den der Nutzer gerade angeklickt hat. Mit toObservable()<\/code> k\u00f6nnen wir jedes mal, wenn selectedMovie<\/code> sich \u00e4ndert reagieren und in der Observable-Pipeline einen weiteren HTTP-Request machen, mit dem wir die Charaktere des Films abfragen. Die entsprechende Antwort fangen wir dann mit dem movieCharacters$<\/code> Observable ab.<\/p>\n
\n
\n
selectedMovie = signal<Movie | undefined>(undefined);\r\n\r\nprivate movieCharacters$ = toObservable(this.selectedMovie).pipe( \r\n  \/\/... Siehe den vollst\u00e4ndigen Code im StackBlitz-Projekt weiter unten\r\n  switchMap(movie => this.http.get<Character>(movie.characterUrl))\r\n);<\/pre>\n<\/div>\n<\/div>\n
Somit k\u00f6nnen wir auf synchrone Zustands\u00e4nderungen mit asynchronen Operationen reagieren. Das movieCharacter$<\/code> Observable kann jetzt auch wieder mit einem Signal f\u00fcr Templates verf\u00fcgbar gemacht werden.
\nMit der toSignal()<\/code> und toObservable()<\/code> Funktion lassen sich asynchrone Vorg\u00e4nge sehr gut im Service abhandeln und kapseln. Nach au\u00dfen sind dann nur Signals zug\u00e4nglich, die dem synchronen State Management dienen.<\/p>\n
ngxtension<\/h2>\n
ngxtension<\/a> ist eine Bibliothek mit Hilfsfunktionen f\u00fcr Angular, welche das Entwickeln mit Angular einfacher machen sollen. Mittlerweile gibt es auch schon mehr als zehn Funktionen, die die Arbeit mit Signals erleichtern. Wir m\u00f6chten jetzt noch zwei dieser Funktionen vorstellen, die wir am praktischsten finden.<\/p>\n
toLazySignal()<\/h3>\n
Die Funktion toLazySignal()<\/a> funktioniert \u00e4hnlich wie die originale toSignal()<\/code> Funktion, mit der Ausnahme, dass nicht sofort eine Subscription erzeugt wird. toLazySignal()<\/code> setzt also genau da an, wo wir oben bei toSignal()<\/code> ein Problem gesehen haben. Erst wenn das Signal das erste Mal gelesen wird, subscribed Angular an das entsprechende Observable.<\/p>\n
const people = toSignal(this.people$);\r\n\r\nconst planets = toLazySignal(this.planets$);<\/pre>\n
An diesem Code-Schnipsel kann man sehen, dass die Funktionen genau gleich verwendet werden. Im eingebundenen StackBlitz-Projekt haben wir die beiden Funktionen in einer Komponente auch nochmal gegen\u00fcber gestellt, damit Du die Subscriptions selber ausprobieren kannst.<\/p>\n
connect()<\/h3>\n
Die connect()<\/a> Funktion verkn\u00fcpft ein Signal mit einem Observable. Das klingt jetzt erstmal nicht anders als die toSignal()<\/code> Funktion, aber w\u00e4hrend man bei toSignal()<\/code> nur ein readonly Signal erh\u00e4lt, liefert connect()<\/code> ein writeable Signal.<\/p>\n
Wenn man also den Wert eines Signals basierend auf einem Observable setzen will, kann man das wie im folgenden Beispiel machen:<\/p>\n
\n
connect(this.signalName, this.connectForm.valueChanges);<\/pre>\n<\/div>\n
Das Signal signalName<\/code> wird dabei an das valueChanges<\/code> Observable der FormControl gekn\u00fcpft. Immer wenn sich das Formular updated, weil der eingetragene Wert ge\u00e4ndert wird, aktualisiert sich auch das Signal.<\/p>\n
connect()<\/code> hat aber nicht nur diesen einen Anwendungszweck. Es ist ebenfalls m\u00f6glich zwei Signals miteinander zu verkn\u00fcpfen, wobei man auch wieder ein writeable Signal erh\u00e4lt, und connect()<\/code> erm\u00f6glicht auch, dass eine beliebige Anzahl von Streams mit nur einem Signal verbunden werden kann. Es gibt also eine Vielzahl von Anwendungsf\u00e4llen, wo die connect()<\/code> Funktion einem die Arbeit erleichtert.<\/p>\n
Erfahrung ist der beste Lehrer: Hands-On mit Signals und RxJS<\/h2>\n
Bist Du bereit, die Theorie in die Praxis umzusetzen? In diesem interaktiven StackBlitz-Beispiel haben wir eine Beispielanwendung erstellt, die die Grundkonzepte von RxJS und Signals aufgreift und alle vorgestellten Beispiele und Funktionen beinhaltet. Tauche ein und experimentiere, um Signals und RxJS in Aktion zu erleben!<\/p>\n