Wie funktioniert State Management mit NgRx?

Question

Accepted Answer

**NgRx** ist eine Redux-inspirierte State-Management-Bibliothek für Angular. Sie zentralisiert den Anwendungszustand in einem einzigen unveränderlichen **store** mit einem strikten, vorhersehbaren, unidirektionalen Datenfluss, der auf RxJS aufbaut. ## Die Kernkomponenten und der Fluss ```text Component dispatches an ACTION → REDUCER produces new state (pure function) → STORE updates → SELECTORS read state → Component re-renders (EFFECTS handle side effects like HTTP, dispatching new actions) ``` ## Actions — beschreiben, was passiert ist ```ts import { createAction, props } from "@ngrx/store"; export const loadUsers = createAction("[Users] Load"); export const loadUsersSuccess = createAction("[Users] Load Success", props<{ users: User[] }>()); ``` ## Reducer — reine Funktion, die den nächsten Zustand berechnet ```ts import { createReducer, on } from "@ngrx/store"; export const usersReducer = createReducer( initialState, on(loadUsers, state => ({ ...state, loading: true })), on(loadUsersSuccess, (state, { users }) => ({ ...state, users, loading: false })), ); ``` Reducer sind **rein** — bei gegebenem aktuellen Zustand und einer Action geben sie ein brandneues State-Objekt zurück (unveränderlich), verändern den alten niemals. ## Effects — verarbeiten Nebenwirkungen (HTTP usw.) ```ts loadUsers$ = createEffect(() => this.actions$.pipe( ofType(loadUsers), switchMap(() => this.api.getUsers().pipe( map(users => loadUsersSuccess({ users })) // dispatch success with the data ) ) ) ); ``` Effects lauschen auf Actions, führen asynchrone Arbeit durch (wie HTTP) und versenden Result-Actions — halten Nebenwirkungen aus Komponenten und Reducern heraus. ## Selectors + Komponentennutzung ```ts export const selectUsers = createSelector(selectUsersState, s => s.users); // memoized // component users$ = this.store.select(selectUsers); load() { this.store.dispatch(loadUsers()); } ``` ```html

``` ## Wann lohnt sich NgRx? ```text ✓ Large apps with lots of shared state across many components ✓ Complex state interactions, need for time-travel debugging / strict predictability ✗ Small/medium apps → it's heavy boilerplate; a service + signals/BehaviorSubject is simpler ``` (Hinweis: NgRx bietet auch ein leichteres **SignalStore** und **ComponentStore** für weniger Boilerplate.) ## Warum es wichtig ist NgRx bringt Reduxs vorhersehbares, zentralisiertes, unidirektionales State Management zu Angular — wertvoll für große Apps, in denen viele Komponenten komplexen Zustand teilen, und wo strikte Nachverfolgbarkeit und Debugging zählen. Aber es bringt erhebliches Boilerplate mit sich, daher ist die Schlüsselabwägung, *wann* es zu verwenden ist (großer/komplexer gemeinsamer Zustand) versus einfachere Ansätze (Services mit Signals oder `BehaviorSubject`) für kleinere Apps. Das Verständnis des Action→Reducer→Store→Selector-Flusses und Effects für Nebenwirkungen ist zentral für die Arbeit in NgRx-Codebases.