Jak wybrać podejście do zarządzania stanem w React?

Question

Accepted Answer

Dopasuj narzędzie do **rodzaju** stanu, zamiast domyślnie sięgać po globalny store. Większość problemów ze "stanem globalnym" to naprawdę niewłaściwe narzędzie do zadania.

## Dlaczego to ważne

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

## Najważniejszy wgląd: server state ≠ client state

Dane z API to **cache** zdalnych danych, a nie stan, który posiadasz. Umieszczenie go w Redux oznacza ręczne obsługiwanie ładowania, cachowania, ponownego pobierania i unieważniania — boleśnie i podatne na błędy. Biblioteka obsługująca state serwera robi to wszystko:

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

## Wytyczne

- Utrzymuj state tak **lokalnie** jak to możliwe; umieść go blisko miejsca, w którym jest używany.
- Nie umieszczaj szybko zmieniających się wartości w **Context** (powoduje ponowne renderowanie wszystkich konsumentów).
- Dla udostępnionego client state z częstymi aktualizacjami preferuj store z **selective subscriptions** (Zustand/Jotai), aby komponenty były re-renderowane tylko dla fragmentu, który czytają.
- Sięgnij po Redux Toolkit, gdy potrzebujesz jego devtools/middleware/struktury do naprawdę złożonego udostępnionego stanu.

Prawdziwa umiejętność to **minimalizowanie i prawidłowe umieszczanie** stanu — nie wybieranie biblioteki.