React
Estado global y stores externos
Explica cuándo el estado necesita salir del árbol de componentes y cómo evaluar Context, reducers y stores externos según alcance, suscripción y consistencia.
- Última actualización
- Actualizada
- Nivel
- Aplicación
React
Explica cuándo el estado necesita salir del árbol de componentes y cómo evaluar Context, reducers y stores externos según alcance, suscripción y consistencia.
Clasifica antes de elegir herramienta:
Puede funcionar para dominios moderados, pero cada cambio del value puede actualizar consumidores amplios. Separa lectura, acciones y contextos cuando corresponda.
Redux Toolkit, Zustand y otras herramientas ofrecen modelos distintos. La elección depende de requisitos, no de popularidad.
Un consumidor debería suscribirse solo al fragmento necesario. Esto reduce acoplamiento y renders.
No dupliques una caché de consultas dentro del store global salvo una razón específica. Server state y client state tienen ciclos diferentes.
Persistir todo puede restaurar datos obsoletos, sensibles o incompatibles. Versiona y limita lo almacenado.
La mejor gestión de estado comienza reduciendo y clasificando el estado, no instalando una biblioteca.
¿quién necesita el dato?
¿quién lo modifica?
¿debe sobrevivir navegación?
¿es remoto o cliente?
¿necesita selectores?Categorías:
Usar una sola store para todo borra estas diferencias.
Context + reducer puede cubrir dominios moderados; una store aporta cuando el patrón de suscripción es el problema.
const total = useCartStore((state) => state.total);El componente se suscribe al resultado del selector. Para evitar actualizaciones innecesarias:
type State = {
productsById: Record<string, Product>;
selectedProductId: string | null;
};Guarda entidades una vez y deriva selecciones. Esto ayuda cuando muchas features actualizan la misma entidad, pero añade indirección. No normalices un formulario pequeño.
Débil:
setState({ ...state, anyField: value });Mejor:
cart.itemAdded(product)
cart.quantityChanged(itemId, quantity)
cart.cleared()Las acciones protegen invariantes y permiten cambiar implementación sin romper consumidores.
<CartStateContext value={state}>
<CartDispatchContext value={dispatch}>
{children}
</CartDispatchContext>
</CartStateContext>Ventajas:
Limitaciones:
No copies queries en una store global solo para “tener todo centralizado”. La caché remota ya gestiona identidad, stale, retry e invalidación. Guarda en cliente únicamente información verdaderamente local, como selectedProductId, y deriva datos desde la query.
const page = searchParams.get("page") ?? "1";Duplicar página o filtros en store crea sincronización con URL. Usa store solo si existe estado no navegable asociado; la URL sigue siendo autoridad para lo compartible.
store → serialize → storage
startup → migrate → validate → hydratePersistir requiere:
No persistas tokens o respuestas completas por defecto. Storage cliente puede leerse y modificarse.
Una store global a nivel de módulo puede compartir datos entre requests en servidor. Crea una instancia por request cuando la arquitectura lo requiera. El snapshot inicial del cliente debe coincidir con el servidor para evitar hydration mismatches.
Las stores deben integrarse con React mediante useSyncExternalStore o la abstracción correcta. Suscribirse manualmente con effect puede producir tearing: componentes leyendo snapshots distintos durante el mismo render.
Prueba por capas:
No reutilices una store singleton entre tests sin reset.
DevTools ayudan a inspeccionar transiciones, pero no reemplazan nombres de acciones y límites. No registres payloads sensibles. Un log de cada tecla puede generar ruido y coste.
Una feature puede empezar en store y después descubrir que solo un componente usa el dato. Reducir alcance mejora comprensión. La arquitectura de estado puede evolucionar en ambas direcciones.
Arquitectura, carpetas y TypeScript en React ubica stores, features y contratos dentro de límites mantenibles.