Come scegli un approccio di state management in React?

Question

IT Interview Practice · Accepted Answer

Abbina lo strumento al **tipo** di state, piuttosto che ricorrere per default a un store globale. La maggior parte dei problemi di "global state" sono in realtà l'uso dello strumento sbagliato.

## Perché è importante

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

## L'insight più importante: server state ≠ client state

I dati provenienti da un'API sono una **cache** di dati remoti, non uno state che possiedi. Metterli in Redux significa gestire manualmente il caricamento, il caching, il refetching e l'invalidazione — doloroso e soggetto a bug. Una libreria di server-state fa tutto questo:

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

## Linee guida

- Mantieni lo state il più **locale** possibile; posizionalo vicino a dove viene utilizzato.
- Non mettere valori che cambiano rapidamente in **Context** (causa re-render di tutti i consumer).
- Per lo shared client state con aggiornamenti frequenti, preferisci uno store con **selective subscriptions** (Zustand/Jotai) in modo che i componenti eseguano il re-render solo per lo slice che leggono.
- Ricorri a Redux Toolkit quando hai bisogno dei suoi devtools/middleware/structure su uno state condiviso genuinamente complesso.

La vera competenza è **minimizzare e posizionare correttamente** lo state — non scegliere una libreria.

Perché è importante

L'insight più importante: server state ≠ client state

Linee guida

Domande correlate