name	ngrx
description	STRÖER-Konventionen für State-Management mit NgRx in Angular (klassischer Store und @ngrx/signals Signal Store). Einsetzen beim Entwerfen, Reviewen oder Refactoren von Actions, Reducers, Effects, Selectors oder Signal Stores.

NgRx — STRÖER-Konventionen

State-Management-Leitplanken für Angular-Apps. Gilt für den klassischen Global Store (@ngrx/store, @ngrx/effects) und den @ngrx/signals Signal Store.

Wann welcher Store

Signal Store (@ngrx/signals) ist die Standardwahl für neue Features — lokaler oder feature-naher State, weniger Boilerplate, Signals-nativ.
Global Store (@ngrx/store) nur für echten, app-weit geteilten State mit mehreren unabhängigen Konsumenten oder komplexen Seiteneffekten.

Do's

Actions event-driven benennen: [Source] Event (z. B. [Login Page] Submit Clicked), nicht als Befehle.
State ausschließlich über Selectors lesen; Komponenten greifen nie direkt in den State.
Selectors klein und komponierbar halten; abgeleitete Werte via createSelector memoisieren.
Reducer pure halten — keine Seiteneffekte, keine Mutationen (immer neue Referenzen).
Alle Seiteneffekte in Effects; externe Calls mit switchMap/concatMap/exhaustMap passend zur Semantik wählen und Fehler im Stream behandeln (catchError).
State-Shape normalisieren (z. B. @ngrx/entity) statt verschachtelter Arrays.
Signal Store mit withState, withComputed, withMethods strukturieren; patchState für Updates verwenden.

Don'ts

Keine Geschäftslogik in Komponenten oder Effects — Logik gehört in Reducer/Selectors bzw. pure Funktionen.
Kein direkter store.select(...).subscribe(...) mit manuellem State-Halten in Komponenten — toSignal/async-Pipe nutzen.
Keine "Command"-Actions, die von mehreren Reducern geteilt werden, um Logik zu sparen.
Reducer nicht für API-Calls oder Navigation missbrauchen.
Kein nicht-serialisierbarer State (Klassen-Instanzen, Funktionen, Promises) im Store.
mergeMap nicht als Default für Effects — führt zu Race Conditions; bewusst wählen.

NgRx — STRÖER-Konventionen

State-Management-Leitplanken für Angular-Apps. Gilt für den klassischen Global Store (@ngrx/store, @ngrx/effects) und den @ngrx/signals Signal Store.

Wann welcher Store

Signal Store (@ngrx/signals) ist die Standardwahl für neue Features — lokaler oder feature-naher State, weniger Boilerplate, Signals-nativ.

Global Store (@ngrx/store) nur für echten, app-weit geteilten State mit mehreren unabhängigen Konsumenten oder komplexen Seiteneffekten.

Do's

Actions event-driven benennen: [Source] Event (z. B. [Login Page] Submit Clicked), nicht als Befehle.

State ausschließlich über Selectors lesen; Komponenten greifen nie direkt in den State.

Selectors klein und komponierbar halten; abgeleitete Werte via createSelector memoisieren.

Reducer pure halten — keine Seiteneffekte, keine Mutationen (immer neue Referenzen).

Alle Seiteneffekte in Effects; externe Calls mit switchMap/concatMap/exhaustMap passend zur Semantik wählen und Fehler im Stream behandeln (catchError).

State-Shape normalisieren (z. B. @ngrx/entity) statt verschachtelter Arrays.

Signal Store mit withState, withComputed, withMethods strukturieren; patchState für Updates verwenden.

Don'ts

Keine Geschäftslogik in Komponenten oder Effects — Logik gehört in Reducer/Selectors bzw. pure Funktionen.

Kein direkter store.select(...).subscribe(...) mit manuellem State-Halten in Komponenten — toSignal/async-Pipe nutzen.

Keine "Command"-Actions, die von mehreren Reducern geteilt werden, um Logik zu sparen.

Reducer nicht für API-Calls oder Navigation missbrauchen.

Kein nicht-serialisierbarer State (Klassen-Instanzen, Funktionen, Promises) im Store.

mergeMap nicht als Default für Effects — führt zu Race Conditions; bewusst wählen.