React 19 de Cero a Experto / Estado global

Qué herramienta de estado usar (mapa de decisión)

Teoría22 min20 XP

Ya conoces todas las herramientas de estado de React: useState, useReducer, lifting, Context, Zustand, TanStack Query, máquinas de estado. La pregunta que confunde a todos no es "¿cómo funciona cada una?" sino "¿CUÁL uso para esto?". Elegir mal —Context para datos de API, Redux para un toggle— es la fuente de la mayoría del código sobre-complicado. Hoy pones orden con un mapa de decisión claro, incluido el lugar honesto de Redux Toolkit.

La pregunta correcta primero

El mapa de decisión

Del más simple al más complejo: elige el primero que te sirva

Recorre esta lista de arriba hacia abajo y quédate con el PRIMERO que resuelva tu caso. La disciplina es no subir de nivel sin necesidad:

Estado local → useState. Vive en un componente y no lo necesita nadie más: el texto de un input, si un modal está abierto, un contador. La mayoría del estado es esto. Empieza SIEMPRE aquí.
Estado local complejo → useReducer. El mismo estado local, pero con muchas transiciones o forma de máquina (módulos 2 y 4). Sigue siendo local; solo más organizado.
Compartido por pocos, cerca → lifting state up. Dos o tres componentes hermanos lo necesitan: súbelo al ancestro común (módulo 2). No saques artillería para esto.
Global, estable, de ambiente → Context. Muchos componentes lejanos lo necesitan y cambia POCO: tema, usuario autenticado, idioma. Resuelve el prop drilling sin dependencias.
Global, cambia seguido, con selectores → Zustand. Estado de UI compartido que cambia a menudo y quieres que solo re-renderice quien usa la parte que cambió. El "default pragmático".
Datos del servidor → TanStack Query. Cualquier cosa que venga de una API. NO va en Context ni Zustand: tiene su propia herramienta con caché, revalidación y mutaciones (módulo 5). Este es el error más común: tratar datos de servidor como estado de cliente.
Flujos con reglas → máquina de estados (useReducer o XState). Cuando el estado es un flujo con transiciones estrictas (módulo anterior).

La regla de oro: la mayoría de las apps necesitan sorprendentemente poco estado global. Mucho de lo que la gente mete en Redux/Context es en realidad estado de servidor (→ TanStack Query) o estado local que no hacía falta compartir. Clasifica bien y el estado global se encoge.

El lugar de Redux (Toolkit)

¿Y Redux? Cuándo sí, cuándo no

Redux fue durante años el estándar de estado global en React. Hoy Redux Toolkit (RTK) es su versión moderna y oficial —mucho menos boilerplate que el Redux clásico, con createSlice e Immer para escribir "mutaciones" que por dentro son inmutables—. ¿Cuándo tiene sentido?

Sí a RTK: apps grandes con muchos desarrolladores donde el rigor ayuda (un flujo de datos muy explícito y predecible), necesidad de las Redux DevTools con viaje en el tiempo, middleware complejo, o un equipo que ya lo conoce y domina. En esos contextos, su estructura es una ventaja.
No a RTK para empezar: para la mayoría de apps nuevas es MÁS de lo que necesitas. Zustand da el 90% del beneficio con una fracción del código, y TanStack Query se lleva el estado de servidor que antes llenaba los stores de Redux. Por eso el consejo actual del ecosistema es: para estado de cliente, Zustand; para estado de servidor, TanStack Query; y RTK cuando su rigor y ecosistema justifiquen el costo.

No es que Redux esté "mal" —RTK es excelente en su terreno—; es que el problema que Redux resolvía se partió en dos (cliente → Zustand, servidor → TanStack Query), y para muchas apps esas dos piezas ligeras bastan.

Tienes datos que vienen de una API (la lista de gastos del servidor) y varios componentes los muestran. ¿Dónde va ese estado?

Mini-reto

Clasifica el estado de una app de gastos y elige herramienta para cada uno, justificando: (a) si el menú lateral está abierto; (b) el tema claro/oscuro; (c) la lista de gastos que viene de GET /api/gastos; (d) el borrador de un formulario de nuevo gasto mientras se escribe; (e) el paso actual de un asistente de "configurar presupuesto" de 4 pantallas con reglas de avance; (f) el usuario autenticado. Para cada uno, di el nivel del mapa (1 a 7) y por qué.

Qué sigue

Cierras el módulo aplicando el mapa: una "Mi Bolsillo" donde el estado global vive en un store compartido (sin prop drilling) y varios componentes lo leen y lo cambian. Consolidarás Context/store global en una app real —y verás por qué clasificar bien el estado hace el código más simple, no más complejo—.