Hoe kies je een state management-benadering in React?

Question

Accepted Answer

Stem het gereedschap af op het **type** state, in plaats van automatisch naar een global store te grijpen. De meeste "global state"-problemen zijn eigenlijk het verkeerde gereedschap voor het werk.

## Beslissingshandleiding

```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)
```

## Het belangrijkste inzicht: server state ≠ client state

Gegevens van een API zijn een **cache** van externe gegevens, geen state die je bezit. Het in Redux stoppen betekent dat je handmatig loading, caching, refetching en invalidatie afhandelt — pijnlijk en foutgevoelig. Een server-state bibliotheek doet dit allemaal:

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

## Richtlijnen

- Houd state zo **lokaal** mogelijk; plaats het dicht bij waar het gebruikt wordt.
- Plaats niet snel veranderende waarden in **Context** (dit re-rendert alle consumers).
- Voor gedeelde client state met frequente updates, geef de voorkeur aan een store met **selective subscriptions** (Zustand/Jotai) zodat componenten alleen opnieuw renderen voor het stuk dat ze lezen.
- Grijp naar Redux Toolkit wanneer je de devtools/middleware/structuur ervan nodig hebt op echt complexe gedeelde state.

De echte vaardigheid is **state minimaliseren en correct plaatsen** — niet het kiezen van een bibliotheek.