Wie wählst du einen State-Management-Ansatz in React?

Question

Accepted Answer

Passe das Tool zur **Art** des States an, anstatt standardmäßig zu einem globalen Store zu greifen. Die meisten "globalen State"-Probleme sind wirklich die falsche Lösung für das Problem.

## Warum es wichtig ist

```text
Local UI state (toggle, input)      → useState / useReducer
Shared, low-frequency (theme, user) → Context
Server/API data                     → React Query / SWR  (NOT a global store)
Complex global client state         → Zustand / Jotai / Redux Toolkit
URL-shareable state (filters, page) → the URL (search params)
```

## Die wichtigste Erkenntnis: Server State ≠ Client State

Daten von einer API sind ein **Cache** entfernter Daten, kein State, den du besitzt. Sie in Redux zu speichern bedeutet, dass du manuell Loading, Caching, Refetching und Invalidation handhabst — schmerzhaft und fehleranfällig. Eine Server-State-Bibliothek erledigt all das:

```jsx
// handles caching, dedup, background refetch, stale-while-revalidate for free
const { data, isLoading } = useQuery({ queryKey: ["todos"], queryFn: getTodos });
```

## Richtlinien

- Halte State so **lokal** wie möglich; ordne ihn in der Nähe des Verwendungsortes an.
- Lege schnell wechselnde Werte nicht in **Context** (es rendert alle Consumer neu).
- Für gemeinsamen Client State mit häufigen Updates bevorzuge einen Store mit **selektiven Subscriptions** (Zustand/Jotai), damit Components nur für den Slice neu rendert werden, den sie lesen.
- Greife zu Redux Toolkit, wenn du seine Devtools/Middleware/Struktur für wirklich komplexen gemeinsamen State brauchst.

Die echte Fähigkeit ist **State zu minimieren und korrekt zu platzieren** — nicht eine Bibliothek auszuwählen.