Zoneless Change Detection und RxJS-Interoperabilität

Zoneless und RxJS-Interop

0:00 Jetzt kommen wir zu der Änderung, die unter der Oberfläche am tiefsten geht. Angular hat sich von Zone.js verabschiedet — der Bibliothek, die jahrelang jede asynchrone Operation umschlossen und Angular danach angestoßen hat. Der Unterschied lässt sich in einem Satz sagen: Angular erkennt Änderungen nicht mehr von selbst, es wird benachrichtigt.

0:20 Das klingt nach weniger Komfort und ist in Wahrheit weniger Magie. Und weniger Magie heißt: nachvollziehbar, wenn etwas nicht funktioniert.

Reaktivität und Anwendungsstruktur

0:29 Wir bleiben beim Thema Reaktivität. Gestern haben wir modelliert, was sich ändern kann. Heute klären wir, wie Angular davon erfährt — und wann Signals das richtige Mittel sind und wann doch ein Stream.

Wie Angular Änderungen erkennt

0:42 Fangen wir mit dem Mechanismus an. Wer versteht, was eine Aktualisierung auslöst, versteht auch alle Fehler, die in diesem Bereich auftreten können — und es sind immer dieselben drei. Früher lief es so: Zone.js hat jeden Timer, jede Netzanfrage, jeden Klick umschlossen und Angular anschließend gesagt, schau mal nach, ob sich was geändert hat.

1:03 Das war bequem und ziemlich grob. Heute löst aus, was Angular ausdrücklich gemeldet wird — eine Signal-Änderung im Template, ein gebundenes Ereignis, das Setzen einer Eingabe oder die ausdrückliche Markierung. Seit Angular 21 ist zoneless der Normalfall, seit 22 ist OnPush die Standardstrategie. Stellen Sie sich den Unterschied vor wie zwischen einem Wachdienst, der alle zehn Minuten durchs ganze Haus geht, und einer Klingel an jeder Tür.

1:30 Die linke Spalte erklärt, warum ältere Angular-Anwendungen manchmal unerklärlich langsam waren. Jeder Timer, auch einer aus einer Bibliothek, die mit Ihrer Oberfläche gar nichts zu tun hat, löste eine Prüfung aus — und zwar von oben nach unten durch den ganzen Komponentenbaum. Rechts wird nur markiert, was betroffen ist. Der zweite Unterschied ist mir fast noch wichtiger: Fremdcode löste früher mit aus, ohne dass jemand das steuern konnte.

1:55 Heute muss er melden. Das ist unbequemer und dafür vorhersehbar. Vier Punkte, und nur der erste ist der Leistungsaspekt. Weniger Durchläufe heißt weniger Rechenarbeit, klar. Aber die anderen drei sind im Alltag oft wertvoller. Die Auslöser stehen im Code statt in einer umschließenden Zone — Sie können sie lesen. Die Fehlersuche wird einfacher, weil der Aufrufweg nicht mehr durch Zone.js führt; wer jemals einen Stacktrace mit zwanzig Zone-Zeilen gesehen hat, weiß, was das wert ist.

2:25 Und die Auslieferung wird kleiner, weil das Polyfill wegfällt. Der erste Punkt ist der ärgerlichste: Zone.js bleibt über eine Abhängigkeit im Projekt und hebt den ganzen Vorteil auf. Sie haben es aus der Konfiguration entfernt, und ein Paket zieht es wieder herein. Der zweite ist der häufigste: Eine Komponente ändert ein Feld direkt und meldet nichts — die Ansicht bleibt stehen.

2:48 Und der dritte ist der, der bei Umstellungen bestehender Anwendungen zuerst auffällt: Reactive Forms melden ihren Zustand nicht von selbst. Das ist kein Fehler, sondern eine Folge der Architektur — und ein Thema für Modul neunzehn.

Signals und Streams gegeneinander abwägen

3:01 Damit zur Frage, die in jedem Angular-Team irgendwann diskutiert wird und die man besser einmal entscheidet als fünfzigmal: Signal oder Stream? Die Unterscheidung ist einfacher, als die Diskussion vermuten lässt. Ein Signal hält einen Wert. Ein Observable beschreibt einen Ablauf über die Zeit. Wenn Sie wissen wollen, wie der Filter gerade steht, ist das ein Wert — Signal.

3:24 Wenn Sie Eingaben entprellen, mehrere Quellen zusammenführen oder eine laufende Anfrage abbrechen wollen, geht es um zeitliche Abläufe — Stream. RxJS verschwindet also nicht aus Angular. Es bekommt nur einen klareren Platz: dort, wo der Verlauf zählt, nicht dort, wo nur der aktuelle Wert gebraucht wird. Lesen Sie diese Tabelle nicht als Liste, sondern als eine einzige Frage in fünf Varianten: Brauche ich den Verlauf oder nur den aktuellen Stand?

3:52 Alles in der oberen Hälfte ist ein Zustand, den jemand anschaut. Alles darunter hat mit Zeit zu tun — entprellen, zusammenführen, abbrechen. Und die letzte Zeile ist noch einmal ein Zustand. Wenn Sie in Ihrem Team unsicher sind, stellen Sie diese eine Frage. Sie beantwortet erfahrungsgemäß neun von zehn Fällen, und der zehnte ist dann eine echte Diskussion wert.

4:14 Vier Schritte, und der letzte ist der eigentliche Zweck. Sie fragen nach dem Verlauf, wählen entsprechend, führen Streams am Rand in ein Signal über — und dann schreiben Sie die Regel auf. Nicht weil sie kompliziert wäre, sondern weil ohne aufgeschriebene Regel beide Muster nebeneinander entstehen, für denselben Zweck. Ein Kollege löst es mit einem Subject, die andere mit einem Signal, beides funktioniert, und in einem Jahr weiß niemand mehr, welches der beiden das gewollte ist.

4:42 Der erste Punkt ist die klassische Altlast: Ein Subject ersetzt ein Signal, und niemand weiß, wer den aktuellen Wert hält. Ein Subject hat nämlich keinen — man muss ihn mitführen. Der zweite ist Aufwand ohne Gegenwert: Eine Kette von Operatoren bildet nach, was eine Ableitung in einer Zeile leistet. Und der dritte ist der, der die Vorteile der Signals wieder aufhebt: Zustand wird abonniert und in ein Feld geschrieben.

5:06 Dann haben Sie wieder ein Feld, das Angular nichts meldet — und sind bei den Fehlern von vorhin.

Brücken zwischen beiden Welten

5:13 Gut, wir haben zwei Welten. Jetzt die Werkzeuge, mit denen man zwischen ihnen wechselt — und die sind erfreulich unspektakulär. Es gibt eine Funktion in jede Richtung. Die eine macht aus einem Observable ein Signal, mit ein paar Optionen — vor allem einem Anfangswert, damit das Signal nicht zunächst undefiniert ist. Die andere geht den umgekehrten Weg. Eine dritte beendet ein Abonnement automatisch mit der Komponente.

5:39 Wichtig ist der Ort: Alle brauchen einen Injektionskontext, also den Zeitpunkt, an dem die Komponente oder der Service gerade aufgebaut wird. Das ist die häufigste Fehlerquelle beim ersten Einsatz. Dieses Beispiel ist der einzige Ort in unserer ganzen Anwendung, an dem RxJS vorkommt — und es zeigt genau, wofür. Der Benutzer tippt, jeder Tastendruck wäre eine Suchanfrage.

6:02 Entprellen und Doppelte aussortieren sind zeitliche Operationen; dafür ist ein Stream gemacht. Und dann endet der Stream nicht in einem Feld, sondern in einem Signal. Ab da ist der Wert wieder normaler Zustand, den jede Ableitung lesen kann. Das ist das Muster, das ich Ihnen mitgeben möchte: Stream für die Zeit, Signal für den Zustand, und eine klare Übergabestelle dazwischen.

6:26 Vier Fallen, drei davon kosten Minuten, eine kostet Stunden. Ohne Anfangswert liefert das Signal zunächst „undefiniert", und jede Ableitung muss diesen Fall mitbehandeln. Der Aufruf außerhalb des Injektionskontexts erzeugt eine klare Fehlermeldung — unangenehm, aber schnell behoben. Das von Hand gehaltene Abonnement, das nie beendet wird, ist die teure Variante: Es fällt nicht auf, bis die Anwendung nach zwanzig Minuten Benutzung langsam wird.

6:52 Und die vierte ist eine Eigenschaft, kein Fehler: Bei schnellen Signal-Änderungen erreicht nur der letzte Wert das Observable.

Typische Aktualisierungsfehler

7:00 Bleibt der praktische Teil: Was tun Sie, wenn die Ansicht stehen bleibt? Denn das wird passieren, und es ist jedes Mal eine von drei Ursachen. Im zoneless Betrieb äußert sich ein fehlender Hinweis immer gleich: Die Ansicht steht still, obwohl der Wert längst neu ist. Drei Ursachen decken fast alle Fälle ab. Erstens: Die Änderung passiert außerhalb des gemeldeten Bereichs. Zweitens: Ein Objekt wird verändert statt ersetzt, und die Gleichheitsprüfung sieht keinen Unterschied.

7:30 Drittens: Fremdcode schreibt, ohne zu melden. Im Test zeigt sich dasselbe als Fehlschlag, wenn auf Stabilität gewartet wird — und das ist die freundlichere Variante, weil sie früher kommt. Vier Schritte, und der dritte ist der, an dem sich entscheidet, ob Sie den Fehler beheben oder verdecken. Sie prüfen zuerst, ob überhaupt geändert oder nur mutiert wurde.

7:51 Dann, ob es aus Fremdcode kommt. Dann stellen Sie den Wert auf ein Signal um — statt die ausdrückliche Markierung nachzurüsten. Die Markierung ist die Notlösung für Fremdcode, den Sie nicht ändern können; für eigenen Zustand ist sie das Übertünchen der Ursache. Und der vierte Schritt hält den Fall fest: ein Test, der ohne die Änderung fehlschlägt.

8:12 Der erste Punkt ist der mit Abstand häufigste in bestehenden Anwendungen: Ein Array wird mit „push" erweitert, die Referenz bleibt gleich, und nichts passiert. Der zweite ist der, bei dem man am längsten sucht, weil der eigene Code völlig richtig aussieht: Ein Rückruf einer fremden Bibliothek schreibt ein Feld ohne Meldung.

8:30 Und der dritte ist die Reaktion, die man vermeiden sollte: Der Fehler wird mit einem zusätzlichen Durchlauf übertüncht. Das funktioniert, verschiebt das Problem aber nur — und macht die Anwendung wieder langsamer.

Übung

8:43 Stellen wir Spurweite um. Das ist die Übung, in der Sie alle drei Fehlerarten einmal selbst sehen — und das ist ausdrücklich beabsichtigt. Spurweite soll ohne Zone.js laufen. Und weil eine Umstellung allein ein bisschen mager wäre, bekommt die Übersicht gleichzeitig ein Suchfeld, das erst nach kurzer Pause sucht. Damit haben Sie beide Themen des Moduls in einer Übung: Was muss gemeldet werden, und wo endet ein Stream.

9:08 Rechnen Sie damit, dass nach der Umstellung mehrere Ansichten stehen bleiben. Das ist kein Zeichen dafür, dass etwas schiefgegangen ist — es ist der Zweck der Übung. Das Lernziel hat zwei Hälften, die zusammengehören: beurteilen, welche Änderungen gemeldet werden müssen, und Streams gezielt an Signals anschließen. Das Erfolgskriterium ist erfreulich überprüfbar: Die Anwendung läuft ohne Zone.js, keine Ansicht bleibt stehen, die Suche liefert ihr Ergebnis als Signal.

9:36 Wer früh fertig ist, begründet für zwei weitere Stellen schriftlich, ob dort Signal oder Stream richtig ist. Das ist die eigentliche Fähigkeit — die Umstellung selbst macht man einmal, die Entscheidung trifft man ständig. Die Reihenfolge ist bewusst so: erst entfernen, dann kaputt gehen lassen, dann verstehen. Schritt zwei — durchklicken und alle stehenden Ansichten notieren — ist der wichtigste.

10:00 Notieren Sie sie wirklich, bevor Sie etwas reparieren, sonst reparieren Sie die erste und vergessen die dritte. Schritt drei ordnet je Fall die Ursache zu: Mutation, Fremdcode oder fehlendes Signal. Erst danach die Suche, und zum Schluss ein Test für eine der zuvor stehenden Ansichten. Der hält fest, was Sie gerade gelernt haben.

10:21 Die drei Fallen sind die drei Abkürzungen. Zone.js wird aus der Konfiguration entfernt, bleibt aber installiert — dann ist die halbe Wirkung weg. Eine stehende Ansicht wird mit der ausdrücklichen Markierung geheilt, statt auf Signals umzustellen — dann bleibt die Ursache. Und die entprellte Suche wird abonniert und in ein Feld geschrieben — dann haben Sie genau das gebaut, was wir gerade abgeschafft haben.

10:44 Im nächsten Modul geht es um Struktur: Wer liefert eigentlich wem was, und wie tauscht man das aus?