Moderne Standards

Angular — Moderne Standards

0:00 Angular gibt es seit über zehn Jahren, und genau das ist das Problem. Wer heute in ein Angular-Projekt schaut, findet oft Code, der vor sechs Jahren richtig war und seitdem niemand mehr angefasst hat. Das Framework hat sich in dieser Zeit stark verändert — leiser, als es die Versionsnummern vermuten lassen. Signals, Standalone Components, ein neuer Build, eine neue Template-Syntax: Das sind keine Randnotizen, sondern die Voreinstellungen, mit denen neue Projekte heute entstehen.

0:28 In diesem Modul geht es um genau diese Voreinstellungen. Nicht um Geschmack, sondern um das, was Angular selbst empfiehlt — und darum, was Sie davon haben, wenn Sie mitziehen.

Moderne Angular-Standards

0:39 Wir gehen die Voreinstellungen in der Reihenfolge durch, in der sie aufeinander aufbauen. Zuerst die Beispielanwendung, an der wir alles zeigen. Dann die Compiler-Schalter, die Fehler früh sichtbar machen. Danach die Build-Kette, die Angular vor einigen Versionen ausgetauscht hat. Und am Ende die beiden Punkte, die zusammengehören: Signals als neuer Weg, Zustand zu verwalten, und Zoneless als Konsequenz daraus.

1:03 Fünf Themen, die alle eine Gemeinsamkeit haben: Bei einem frisch angelegten Projekt sind sie bereits richtig eingestellt. Interessant werden sie dort, wo ein Projekt älter ist als diese Entscheidungen. Bevor wir einsteigen, kurz zu Ihnen. Die Antworten auf diese drei Fragen verändern, worauf wir den Schwerpunkt legen. Wer auf Angular 20 unterwegs ist, hat vieles davon schon geschenkt bekommen und braucht vor allem die Begründungen.

1:28 Wer ein Projekt aus der Zeit vor Version 17 pflegt, für den ist manches hier ein Migrationsplan. Und die dritte Frage ist die wichtigste: Was soll heute Abend sitzen? Sagen Sie es ruhig konkret — an Signals lässt sich eine Stunde philosophieren oder in zehn Minuten entscheiden, wo im eigenen Projekt der nächste sinnvolle Schritt liegt.

Die Beispielanwendung Nordwerk

1:48 Alles, was wir besprechen, zeigen wir an einer einzigen Anwendung. Das hat einen Grund: Muster verstehen sich schlecht im Leeren. Wenn Sie bei jedem Thema wieder in dieselbe App schauen, sehen Sie nicht nur die Technik, sondern auch, was sie mit dem Rest macht. Schauen wir uns also kurz an, womit wir es zu tun haben. Nordwerk ist ein kleiner Online-Shop für Fahrradteile. Drei Seiten: ein Katalog mit den Teilen, ein Warenkorb und eine Kasse. Mehr nicht.

2:15 Das klingt bescheiden, und das ist Absicht. Diese App ist ungefähr so komplex wie das Beispiel, das man im Kopf hat, wenn man ein Muster zum ersten Mal erklärt bekommt: groß genug, dass es interessant wird, klein genug, dass man sie in zehn Minuten überblickt. Die Produktdaten kommen von einer Schnittstelle unter Slash A-P-I Slash Parts.

2:35 Später wird genau diese App zum Monorepo und zur Micro-Frontend-Anwendung — dieselben Dateien, nur anders geschnitten. Warum ein durchgehendes Beispiel statt für jedes Thema ein frisches? Weil das Umdenken zwischen den Themen mehr Energie kostet, als man vermutet. Wenn Sie schon wissen, was der Katalog tut, können Sie sich beim Thema Signals ganz auf die Signals konzentrieren.

2:58 Dazu kommt ein praktischer Vorteil: Jede Änderung ist sofort im Browser sichtbar, ohne dass man erst eine Datenlage aufbauen muss. Und weil jede Umbaustufe als eigener Git-Branch bereitliegt, können Sie an jeder Stelle einsteigen, ohne alle vorherigen Schritte selbst gemacht zu haben. Das ist gerade dann nützlich, wenn Sie später etwas nachvollziehen wollen.

3:18 Was Sie hier sehen, ist ein Muster, das Ihnen in fast jeder Angular-Anwendung begegnet: eine Listenkomponente, die über Daten iteriert und für jeden Eintrag eine kleinere Komponente rendert. Der Katalog macht das mit den Teilen, der Warenkorb macht dasselbe mit den Positionen — und beide benutzen dieselbe Detail-Komponente.

3:36 Genau das ist der Punkt, an dem später die Frage nach der Change Detection interessant wird: Wenn Sie im Katalog auf einen Kaufen-Knopf drücken, wie viele dieser Detail-Komponenten rechnen dann neu? Behalten Sie das im Hinterkopf, wir kommen im Performance-Modul darauf zurück. Diese fünf Schritte sind kein Selbstzweck, sondern eine Orientierungsübung. Die ersten beiden bringen die App zum Laufen — Standard, nichts Besonderes.

4:00 Spannend wird der dritte Schritt: Klicken Sie die App wirklich einmal durch, bevor Sie in den Code schauen. Es ist erstaunlich, wie viel leichter Code zu lesen ist, wenn man weiß, was er auf dem Bildschirm bewirkt. Erst danach lohnt der Blick in Katalog, Detail-Komponente und Service. Und der letzte Schritt, der Blick auf die Branches, verrät Ihnen die Dramaturgie des ganzen Seminars — dort steht jede Umbaustufe, die wir noch besprechen werden.

4:26 Diese erste Aufgabe ist bewusst niedrigschwellig, aber sie übt etwas, das man im Alltag ständig braucht: sich in fremdem Code orientieren. Sie haben es geschafft, wenn die App lokal läuft und Sie ohne Nachschauen sagen können, welche Komponente welche Seite rendert. Klingt banal — probieren Sie es trotzdem, es geht schneller schief, als man denkt. Wer mag, macht die Kür: Zeichnen Sie den Weg der Daten vom Service bis ins Template auf Papier.

4:52 Dieser eine Strich, den Sie dabei ziehen, ist der Weg, den wir gleich beim Thema Signals umbauen werden.

Strict Mode für TypeScript und Angular

4:59 Kommen wir zum ersten echten Thema — und es ist zugleich das, was ich in Altprojekten am häufigsten finde. Vier Schalter, die in einer Konfigurationsdatei stehen, in ungefähr fünf Sekunden umgelegt sind und trotzdem in erstaunlich vielen Projekten auf „aus" stehen. Warum das teuer ist, sehen wir jetzt. Vier Schalter also, die nichts kosten und trotzdem regelmäßig fehlen. Schauen wir uns an, was jeder von ihnen verhindert.

5:24 Die Datei heißt tsconfig.json und sieht so aus, als wäre sie nur für TypeScript zuständig. Ist sie aber nicht: Angular hat sich dort einen eigenen Block eingerichtet und legt seine Prüfungen mit hinein. Man kann sich das vorstellen wie die Sicherheitseinstellungen an einem Gerät — es funktioniert auch ohne, aber Sie merken erst später, warum sie da waren.

5:45 Vier dieser Schalter gehören auf „wahr". Bei einem frisch mit der CLI angelegten Projekt sind sie das bereits. Interessant wird es überall dort, wo jemand irgendwann einen davon abgeschaltet hat, um schneller voranzukommen. Alle vier Schalter machen im Kern dasselbe: Sie verschieben Fehler von der Laufzeit in den Compiler. Ein Fehler, den der Compiler findet, kostet Sie dreißig Sekunden.

6:08 Derselbe Fehler in der Produktion kostet einen Support-Fall. Der interessanteste der vier ist der letzte, strictTemplates. Ohne ihn sind die HTML-Templates ein blinder Fleck — dort können Sie an eine Eigenschaft binden, die es gar nicht gibt, und niemand sagt etwas, bis die Seite im Browser leer bleibt. Mit dem Schalter werden Templates so streng geprüft wie der TypeScript- Code daneben. Das ist der größte Einzelgewinn dieser Folie.

6:34 Worauf es hier ankommt, ist nicht die Syntax, sondern die Aufteilung in zwei Blöcke. Oben stehen die TypeScript-Optionen, unten die Angular-Optionen — und das ist die Stelle, an der die meisten stolpern. Wer den Angular-Schalter aus Versehen oben einträgt, bekommt keine Fehlermeldung. Die Datei ist gültig, der Build läuft, der Schalter tut schlicht nichts.

6:55 Ein stiller Fehlschlag, der jahrelang überleben kann. Wenn Sie also in einem Projekt prüfen, ob die Schalter gesetzt sind, prüfen Sie mit: ob sie im richtigen Block stehen. Die Aufgabe klingt nach Buchhaltung, ist aber eine kleine Archäologie. Schauen Sie in ein echtes Projekt und stellen Sie für jeden der vier Schalter fest: an oder aus?

7:15 Geschafft haben Sie es, wenn Sie zu jedem eine Antwort haben — und bei jedem abgeschalteten auch eine Begründung. Denn die gibt es fast immer. Meistens lautet sie: Vor drei Jahren gab es 400 Fehler, und es war gerade keine Zeit. Das ist eine nachvollziehbare Antwort. Sie ist nur eben kein Grund, es heute wieder so zu lassen. Sprechen Sie im Team darüber, statt es stillschweigend zu erben.

7:39 Der erste Punkt ist der ehrlichste: strictTemplates nachträglich einzuschalten, deckt oft dutzende Fehler auf. Das ist kein Argument dagegen — es ist der Beweis dafür, dass der Schalter gebraucht wird. Aber planen Sie den Nachmittag dafür ein, statt es fünf Minuten vor Feierabend zu versuchen. Der zweite Punkt ist der tückischste: Abgeschaltete Schalter reisen mit.

8:00 Jemand kopiert die Konfiguration in ein neues Projekt, und die Entscheidung von damals gilt plötzlich auch für Code, den es noch gar nicht gibt. Und der letzte Punkt: „Läuft doch" ist keine Aussage über Korrektheit, sondern über Glück.

Moderne Build-Tools mit Vite

8:15 Vom Compiler zur Build-Kette. Dieses Thema merkt man nicht an der Anwendung, sondern an der eigenen Geduld: Es geht darum, wie lange Sie warten, wenn Sie etwas ändern. Angular hat hier vor einigen Versionen leise das Werkzeug ausgetauscht — und es lohnt sich zu wissen, auf welcher Seite dieses Wechsels Ihr Projekt steht.

8:33 Und die Antwort darauf ist erfreulich einfach: Sie steht in einer einzigen Zeile Ihrer Paketkonfiguration. Jahrelang war webpack der Standard, mit dem Web-Anwendungen gebündelt wurden. Seit Angular 17 ist es Vite — der Name kommt vom französischen Wort für schnell, und das ist wörtlich gemeint. Der Unterschied merkt man nicht am fertigen Produkt, sondern im Alltag: Wie lange dauert es vom Speichern bis zur aktualisierten Seite?

8:58 Erkennen können Sie den Unterschied an einer einzigen Zeile in den Abhängigkeiten. Steht dort at-Angular-Slash-Build, läuft Vite im Hintergrund. Steht dort das alte Build-Angular-Paket, ist es noch webpack. Beides sind Angular-Verpackungen um ein fremdes Werkzeug — ausgetauscht wurde das, was darin steckt. Der Gewinn ist unspektakulär und genau deshalb wertvoll: Sie warten weniger. Das klingt nach Bequemlichkeit, ist aber ein Qualitätsfaktor.

9:25 Wer nach jeder Änderung zwanzig Sekunden wartet, probiert weniger aus und prüft seltener nach. Kürzere Wartezeiten verändern also, wie sorgfältig man arbeitet. Der zweite Punkt ist praktisch: Bei neuen Projekten müssen Sie gar nichts tun, das kommt fertig. Und bei bestehenden ist die Migration in der Regel ein einzelner Kommandozeilenaufruf und kein Umbau der Anwendung.

9:48 Das Verhältnis von Aufwand und Ertrag ist hier so günstig wie selten. Zwei Dinge passieren hier. Erst die Diagnose: ein Blick in die Paketkonfiguration verrät, welcher Builder läuft. Dann die Behandlung: ein Update-Aufruf mit einem Namen, der etwas sperrig klingt, aber genau das tut, was er sagt — er stellt das Projekt auf den neuen Application Builder um.

10:09 Wichtig ist der Satz darunter, nicht der Befehl darüber. Nach so einer Migration reicht es nicht, dass der Build durchläuft. Lassen Sie die Tests laufen und klicken Sie die Anwendung im Browser durch. Ein grüner Build ist eine Aussage über den Compiler, nicht über Ihre Anwendung. Eine kleine Aufgabe mit einer angenehmen Eigenschaft: Sie ist in zwei Minuten erledigt und beantwortet trotzdem eine Frage, die viele Teams nicht sicher beantworten können.

10:36 Geschafft haben Sie es, wenn Sie belegen können — nicht vermuten —, auf welchem Builder Ihr Projekt läuft. Belegen heißt hier: Sie zeigen auf die Zeile in der Paketkonfiguration. Kommt dabei webpack heraus, lesen Sie vor der Migration den entsprechenden Abschnitt der Angular-Dokumentation. Dort stehen die Sonderfälle, die eine eigene Build-Konfiguration betreffen können.

10:57 Der erste Punkt überrascht viele: Ein modernes Angular garantiert noch keinen modernen Build. Beim Aktualisieren darf man den Wechsel überspringen, und das tun Teams gelegentlich unter Zeitdruck — die Entscheidung überlebt dann alle folgenden Updates. Es kann also sein, dass Sie auf Angular 20 sitzen und trotzdem webpack bauen. Der zweite Punkt ist der Klassiker nach jeder Migration: Man prüft den Build und vergisst die Tests.

11:22 Und der dritte betrifft alle, die sich irgendwann eine eigene webpack-Konfiguration gebastelt haben — die überlebt den Wechsel nicht ungeprüft.

Signals für einfache Reaktivität

11:30 Jetzt kommen wir zum Kern des modernen Angular. Die beiden nächsten Kapitel gehören zusammen: Signals sind der neue Weg, Zustand zu verwalten, und Zoneless ist das, was dadurch möglich wird. Fangen wir mit den Signals an — und mit einer Klarstellung, die wichtiger ist als alles andere: Es geht hier nicht darum, RxJS loszuwerden.

11:50 Und wir klären eine Frage, die in Teams für erstaunlich hitzige Diskussionen sorgt: wann Signals und wann weiterhin RxJS. Ein Signal ist ein Wert, der weiß, wer ihn liest. Das klingt harmlos, ist aber der entscheidende Unterschied. Stellen Sie sich einen Zeitungsabonnenten vor: Bisher musste jeder, der etwas mitbekommen wollte, ein Abo abschließen und daran denken, es wieder zu kündigen.

12:14 Beim Signal ist es umgekehrt — es merkt sich selbst, wer hineingeschaut hat, und sagt genau diesen Stellen Bescheid, wenn sich etwas ändert. Kein Abonnieren, kein Kündigen, kein manuelles Anstoßen des Renderns. Für lokalen Zustand ist das schlicht der einfachere Weg, und deshalb ist es heute die Voreinstellung. Diese Tabelle ist keine Gegenüberstellung von gut und schlecht, sondern eine Arbeitsteilung.

12:39 Die Faustregel dahinter lautet: Geht es um einen Wert, der gerade gilt, nehmen Sie ein Signal. Geht es um eine Abfolge über die Zeit, nehmen Sie RxJS. Ein Warenkorb ist ein Wert — er hat jetzt einen Inhalt. Tastatureingaben, die entprellt werden sollen, sind eine Abfolge — da ist die zeitliche Reihenfolge selbst die Fachlichkeit.

13:00 Wer diese Frage stellt, trifft die Entscheidung fast immer richtig. Und wichtig: RxJS bleibt vollwertig unterstützt. Es ist nur nicht mehr für alles die erste Wahl. Die ersten drei Schritte sind die unstrittigen: Die Dekoratoren für Inputs, Outputs und View-Abfragen werden durch Funktionen ersetzt. Das ist mechanisch, gut migrierbar und die ausdrückliche Empfehlung.

13:23 Schritt vier ist der, über den sich diskutieren lässt: Zustandsdienste auf Signale umzubauen, ist eine Entscheidung, keine Pflicht. Und Schritt fünf ist der wichtigste, weil er die Grenze zieht. Lassen Sie RxJS dort, wo wirklich gestreamt wird. Eine Migration, die auch die letzten sinnvollen Observables ersetzt, hat das Prinzip missverstanden.

13:44 Auf den ersten Blick sieht dieser Service komplizierter aus als die Variante mit einem Observable. Das täuscht — man muss ihn von der anderen Seite betrachten. Entscheidend ist nicht, wie der Service aussieht, sondern was seine Nutzer noch tun müssen. Und die Antwort lautet: nichts. Kein Abonnieren, kein Aufräumen, kein async-Pipe im Template, kein manuelles Anstoßen der Change Detection. Die Ressource bleibt privat, nach außen gehen nur abgeleitete Signale.

14:12 Die Komplexität ist also nicht verschwunden, sondern an eine Stelle gewandert, statt sich auf zehn Komponenten zu verteilen. Genau das ist der Gewinn. Der erste Punkt ist der teuerste, weil er sich als Gespenst tarnt: In einer Anwendung ohne Zone.js aktualisiert sich die Oberfläche einfach nicht, wenn ein manuell abonniertes Observable etwas liefert.

14:33 Kein Fehler, keine Warnung — nur eine Seite, die veraltet. Der zweite Punkt ist der harmlose Klassiker: async-Pipe vergessen, und im Template steht der Objekt-Platzhalter. Der dritte ist die Übertreibung in die andere Richtung. Und der vierte ist ein Entwurfsfehler, den man leicht macht: die Ressource selbst öffentlich machen, statt nur abgeleitete Signale herauszugeben.

14:55 Dann kann jeder von außen daran drehen.

Zoneless-Anwendungen bauen

14:58 Wenn Signals die Antwort auf die Frage sind, wie Zustand verwaltet wird, dann ist Zoneless die Antwort auf die Frage, wann Angular eigentlich neu rendert. Beides hängt zusammen, und deshalb steht dieses Kapitel direkt hinter dem vorigen. Seit Angular 20 fragt die Kommandozeile beim Anlegen eines Projekts danach. Und wie bei den Signals gilt: Der Schritt ist bei einem neuen Projekt trivial und bei einem gewachsenen eine Planungsaufgabe.

15:23 Zone.js hat jahrelang eine bemerkenswerte Aufgabe erfüllt: Es hat praktisch jede asynchrone Funktion des Browsers umgebaut, damit Angular merkt, wenn irgendwo etwas passiert. Man kann sich das vorstellen wie einen Hausmeister, der in jedem Raum einen Bewegungsmelder anbringt, weil er nicht weiß, wo jemand das Licht angemacht hat.

15:42 Das funktioniert — es kostet nur überall ein bisschen. Ohne Zone.js fällt dieser Apparat weg. Angular rendert dann nur noch, wenn ein Signal sich ändert, ein Nutzerereignis auftritt oder jemand es ausdrücklich verlangt. Explizit statt allgegenwärtig. Die Vorteile sind angenehm konkret. Ohne das Umschreiben sämtlicher Browser-APIs läuft die Anwendung schneller und braucht weniger Speicher.

16:06 Das Bundle wird kleiner, weil Zone.js schlicht nicht mehr mitgeliefert wird. Und der Punkt, den ich am wichtigsten finde, steht an dritter Stelle: Change Detection wird vorhersagbar. Wer schon einmal einen halben Tag damit verbracht hat herauszufinden, warum die Oberfläche zu oft oder zu selten neu rechnet, weiß, was das wert ist.

16:25 Aus einem diffusen Verhalten wird eine nachvollziehbare Kette von Ursachen. Die Reihenfolge dieser Schritte ist wichtiger als jeder einzelne davon. Bei neuen Projekten ist es leicht — einmal „ja" sagen, fertig. Bei bestehenden Anwendungen gilt: Zone.js fliegt zuletzt raus, nicht zuerst. Erst muss der Zustand reaktiv sein, erst muss Asynchrones ausdrücklich behandelt werden, erst muss OnPush stehen.

16:50 Wer die Reihenfolge umdreht und mit dem Entfernen anfängt, hat eine Anwendung, die an unvorhersehbaren Stellen einfriert, und keine Fehlermeldung, die dabei hilft. Zoneless ist das Ergebnis der Umstellung, nicht ihr Anfang. Der erste Punkt ist die Umkehrung dessen, was wir gerade besprochen haben, und er passiert trotzdem regelmäßig.

17:10 Der zweite ist der typische Einzelfall: Irgendwo setzt ein verzögerter Aufruf ein Feld, und ohne Zone.js merkt das niemand mehr. Solche Stellen findet man nicht durch Nachdenken, sondern durch Durchklicken. Der dritte Punkt ist der unangenehmste, weil er nicht in Ihrem Code liegt: Fremdbibliotheken, die sich auf das Zone.js-Verhalten verlassen, fallen oft erst spät auf.

17:31 Und der vierte ist eine Frage der Planung — bei einer gewachsenen Anwendung ist das kein Nachmittag. Wenn Sie aus diesem Modul einen Gedanken mitnehmen, dann diesen: Nichts von dem, was wir besprochen haben, ist Geschmackssache. Strict Mode und Vite kommen bei einem neuen Projekt fertig eingestellt heraus — sie sind also keine Empfehlung, sondern die Voreinstellung, von der sich manche Projekte im Lauf der Jahre entfernt haben.

17:56 Signals und RxJS teilen sich die Arbeit, statt einander zu ersetzen. Und Zoneless ist kein Schalter, sondern das Ergebnis einer Umstellung, an deren Ende die Change Detection endlich nachvollziehbar ist. Fünf Punkte, ein gemeinsamer Nenner: weniger Magie, mehr Absicht.

Fragen & Weiterarbeiten

18:12 Damit ist der Boden gelegt. Im nächsten Modul geht es weiter mit der Frage, wie Angular-Code heute geschrieben und strukturiert wird: Standalone Components, die neue Control-Flow-Syntax und die offiziellen Konventionen aus dem Style Guide. Das ist der Teil, der Ihren Code für andere Entwicklerinnen und Entwickler auf Anhieb wiedererkennbar macht.

18:31 Wenn Sie zwischendurch nachlesen möchten: Der Leitfaden zu Zoneless steht in der Angular-Dokumentation und beantwortet die Detailfragen, die wir hier nur angerissen haben. Fragen gerne jetzt — sonst sehen wir uns im nächsten Modul.