| Typ | Konzept |
|---|---|
| Quellen | Quelle - Angular Mastery Workshop Quelle - Recherche - Angular heute 2026 |
| Erstellt | 2026-09-26 |
| Aktualisiert | 2026-09-26 |
| Tags | angular, softwarearchitektur, zustand, heuristik |
Die Verwaltung des Zustands (der Daten) einer Anwendung: wo er liegt, wer ihn ändern darf und wie er über mehrere Orte synchron bleibt. Der Angular-Kurs unterscheidet sechs Arten von Zustand und wählt anhand von fünf Heuristiken zwischen Komponente, Service und Bibliothek.
Warum es schwierig ist
Zustand ist schlicht Daten (Quelle - Angular Mastery Workshop, Folie 360). Das Problem ist die Synchronisation: Die Daten liegen an vielen Orten (Backend, URL, Services, Komponenten). Je mehr Orte, desto mehr Abgleich ist nötig. Fehlender oder unvollständiger Abgleich ist eine Hauptquelle von Fehlern. Wird er in jedem Feature neu von Hand gelöst, entstehen Widersprüche. Genau dafür gibt es State-Management-Bibliotheken (Folie 361).
Sechs Arten von Zustand
| Art | Wo | Merkmale | Beispiele |
|---|---|---|---|
| Server-Zustand | Server | langlebig, über API erreichbar, letzte Wahrheit, kann nicht erreichbar sein | Benutzer, Verträge, Produkte |
| Persistenter Zustand | Browser (Speicher) | vom Server geholte Teilmenge, eine Art Cache, geht beim Neuladen verloren | geladene Verträge |
| Client-Zustand | Browser | Ergebnis von Benutzeraktionen, gehört in die URL, damit man Links teilen kann | Filter, Suche, gewählter Kontext |
| URL-/Router-Zustand | URL | Pfad-Parameter (meist persistenter Zustand), Query-Parameter (meist Client-Zustand) | /contract/123456?active=true |
| Transienter Client-Zustand | Browser | nicht in der URL | Position im Video: gilt für mich, nicht für den Empfänger eines Links |
| Lokaler UI-Zustand | Komponente | kurzlebig, stirbt mit der Komponente | aufgeklapptes Akkordeon |
(Folie 363–369)
Fünf Heuristiken
Welcher Ansatz passt, entscheidet der Kurs anhand von fünf Fragen (Folie 372):
- Wie viel Zustand gibt es?
- Wie viel davon wird zwischen Teilen der App geteilt?
- Wie lange lebt er?
- Wie komplex sind Zustand und Zusammenspiel?
- Wie komplex sind die Nebeneffekte (z.B. Backend-Aufrufe)?
Grob gilt: wenig und isoliert → Komponente; mehr und geteilt → Service; viel, geteilt und komplex → Bibliothek (Folie 373).
Drei Ansätze
| Ansatz | Vorteile | Nachteile |
|---|---|---|
| Komponente | einfach und explizit, Zustand bleibt pro Route isoliert | ad hoc, kein Teilen mit unabhängigen UI-Teilen, mühsam ab 3 Verschachtelungsebenen, schlecht für Asynchrones |
Service mit BehaviorSubject |
Zustand als Strom, OnPush möglich, Änderungen ohne Überschreiben des Alten | Zustand verteilt auf viele Services, kein klares Muster, Konsumenten können Objekte verändern |
| Bibliothek (z.B. NgRx) | Datenfluss in eine Richtung, Nebeneffekte als eigenes Konzept, einheitliches Muster | mehr Code und Lernaufwand |
(Folie 374–383)
Das BehaviorSubject-Muster für Services: Das Subject ist privat, nach aussen gibt es nur ein lesbares Observable und Methoden zum Ändern. So können Komponenten den Zustand nicht an der Service-Logik vorbei ändern (Folie 279, siehe RxJS).
Kurs: Service-Zustand wird mit BehaviorSubject gebaut, für grosse Apps empfiehlt sich der Redux-artige NgRx-Store (Quelle - Angular Mastery Workshop, Folie 279, 383).
Heute: Für Zustand in Services und Komponenten nimmt man meist Signals (signal, computed). NgRx empfiehlt für neue Anwendungen den schlankeren SignalStore (@ngrx/signals, stabil seit NgRx 18). Server-Zustand lässt sich mit resource()/httpResource() laden (Quelle - Recherche - Angular heute 2026).
Die sechs Zustandsarten und die fünf Heuristiken hängen nicht an Angular und gelten für jedes Frontend-Framework. Sie sind ein weiteres Beispiel für Faustregeln statt exakter Entscheidungsverfahren, wie in Heuristiken in BWL und Informatik beschrieben. Die Aussage „Der Server ist die letzte Wahrheit“ entspricht dem Grundsatz dieses Wikis, dass sources/ die unveränderliche Grundlage und wiki/ eine abgeleitete, gepflegte Sicht ist (siehe LLM Wiki).
Verwandt
- NgRx – Bibliothek für grosse Apps
- Reaktive Programmierung – Zustand als Strom oder Signal
- Angular-Komponente – lokaler UI-Zustand und OnPush
- Angular-Architektur – Zustand pro Feature
- Heuristiken in BWL und Informatik – Faustregeln statt Optimierung