Component State vs. Store
Die Frage ist nicht „Store oder kein Store?”. Die Frage ist: Wem gehört dieser Zustand?
Lokal (Component State)
Abschnitt betitelt „Lokal (Component State)“Ein Zustand gehört lokal in die Komponente, wenn:
- Nur diese Komponente ihn braucht
- Er nach Destroy der Komponente irrelevant ist
- Er keine Auswirkungen auf andere Teile des Systems hat
Beispiele: Tooltip-Sichtbarkeit, Formular-Drafts, lokale Filterzustände, UI-Toggle-States.
isDropdownOpen = signal(false);Kein Store. Keine Facade. Direkt in der Komponente.
Geteilter Zustand (Store)
Abschnitt betitelt „Geteilter Zustand (Store)“Zustand gehört in einen Store, wenn:
- Mehrere Komponenten ihn lesen oder schreiben
- Er über Navigation-Grenzen hinweg relevant ist
- Er von Business-Logik abhängt (nicht nur von UI-Logik)
- Er aus einer asynchronen Quelle (API, Events) kommt
Beispiel: Aktuell eingeloggter User, Aufgabenliste, Benachrichtigungen.
Die Anti-Pattern
Abschnitt betitelt „Die Anti-Pattern“- Zu viel im Store: Jeder Tooltip-State im globalen Store. Der Store wird zur Müllhalde.
- Zu wenig im Store: Zustand wird per
@Output()durch fünf Komponenten gereicht, weil „man keinen Store braucht”. - Store als Datenbank: Der Store speichert rohe API-Antworten und Komponenten machen die Mapping-Logik.
Faustformel
Abschnitt betitelt „Faustformel“Wenn du eine zweite Komponente findest, die denselben Zustand braucht, ist es Zeit für einen Store. Nicht früher, nicht später.