¿Cómo eliges un enfoque de gestión de estado en React?

Question

Accepted Answer

Ajusta la herramienta al **tipo** de estado, en lugar de recurrir a un store global por defecto. La mayoría de los problemas de "estado global" son en realidad la herramienta equivocada para el trabajo.

## Una guía de decisión

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

## La idea más importante: el estado del servidor ≠ el estado del cliente

Los datos de una API son un **caché** de datos remotos, no un estado que tú posees. Ponerlos en Redux significa gestionar manualmente la carga, el caché, el refetch y la invalidación — algo doloroso y propenso a errores. Una biblioteca de estado de servidor hace todo eso:

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

## Pautas

- Mantén el estado tan **local** como sea posible; colócalo cerca de donde se usa.
- No pongas valores que cambian rápido en el **Context** (vuelve a renderizar a todos los consumidores).
- Para estado de cliente compartido con actualizaciones frecuentes, prefiere un store con **suscripciones selectivas** (Zustand/Jotai) para que los componentes solo se vuelvan a renderizar por la porción que leen.
- Recurre a Redux Toolkit cuando necesites sus devtools/middleware/estructura sobre un estado compartido genuinamente complejo.

## Por qué es importante

La verdadera habilidad consiste en **minimizar y colocar correctamente** el estado, no en elegir una biblioteca. Hacerlo bien evita re-renders innecesarios, sincronizaciones manuales propensas a errores y la complejidad de mantener un store global donde no hacía falta.