Client State Management

Organizar información que vive en el cliente

Client State Management es la organización arquitectónica del estado mantenido o representado por un cliente: ownership, alcance, lifecycle, representación, derivación, persistencia y coordinación con fuentes externas. Gestiona qué información existe, quién puede cambiarla, cuánto dura y cómo se mantiene interpretable. No se reduce a elegir una biblioteca ni a administrar únicamente caches.

Estado es información que puede afectar comportamiento o representación posteriores: selección, borrador, parámetros de navegación, copia de un producto o petición pendiente. No toda variable merece tratamiento arquitectónico. Importan los datos cuyo ownership, vigencia o supervivencia condicionan una interacción, un contrato o la coherencia entre consumidores.

unidirectional-data-flow trata cómo se propagan cambios; este concepto examina qué estado participa y cómo vive. rendering-strategies estudia dónde y cuándo se produce representación Web. presentation-patterns organiza responsabilidades de presentación. Estas dimensiones pueden combinarse sin convertirse en alternativas equivalentes ni determinar una única solución de state management.

Categorías para preguntar, no una taxonomía universal

La tabla es organización editorial del Atlas. Las categorías pueden superponerse: un borrador puede persistirse y una copia remota puede alimentar valores derivados.

Estado considerado	Ejemplo	Pregunta de ownership y duración
UI efímera	Menú abierto, pestaña seleccionada.	¿Qué interacción lo necesita y cuándo termina?
Edición o borrador	Dirección todavía no aceptada.	¿Quién conserva cambios y qué significa cancelar?
Navegación	Recurso, filtro, página u orden.	¿Debe sobrevivir navegación o poder compartirse?
Compartido del cliente	Contexto de una feature.	¿Quién escribe y qué consumidores observan?
Remoto/cacheado	Precio o PaymentStatus consultado.	¿Quién es autoridad y qué vigencia necesita la copia?
Persistido	Preferencia restaurada.	¿Sigue siendo válida para usuario, versión y sesión?
Derivado	Total visible o lista filtrada.	¿Puede reconstruirse desde entradas identificadas?

Un menú suele permanecer cerca de su interacción; eso no prohíbe compartirlo cuando hay consumidores reales. Una preferencia no sincronizada o un borrador pueden tener autoridad local para su alcance. Una vez compartidos remotamente, las reglas de autoridad requieren otra evaluación: su origen cliente no decide todo su lifecycle.

Alcance, ubicación y autoridad de escritura

Control, pantalla, feature, aplicación, sesión y persistencia entre sesiones describen alcances distintos. Compartido no significa global. Leer desde muchos componentes tampoco concede a todos autoridad para mutar. Un componente puede representar estado gobernado por otra unidad; conocer dónde está almacenado no explica por sí solo su semántica.

Colocar estado cerca de quien lo posee y consume puede limitar coordinación innecesaria. Elevarlo cuando varios consumidores lo necesitan evita otras duplicaciones. React, Sharing State Between Components explica elevar estado al ancestro común pertinente; esa organización de componentes pertenece a React, no impone un árbol universal a todos los clientes.

Un store global puede ayudar con consumidores distantes o workflows transversales y perjudicar si conserva interacciones ya terminadas o mezcla responsables. No existe un número de componentes que obligue a incorporarlo. Redux reconoce estado local y compartido, sin exigir que todo dato entre en su store. Componentes, stores por feature, caches y URL pueden coexistir.

granularity ayuda a examinar acoplamiento: un objeto gigantesco puede vincular cambios ajenos; muchos stores pequeños pueden aumentar coordinación. Una frontera frontend no necesita imitar un servicio backend. Revisar responsabilidades, consumidores y lifecycle, no deducir madurez de la cantidad de stores.

Borrador, confirmación y formulario

En Edit Customer, nombre confirmado y DraftName tienen significados diferentes. Reutilizar una sola copia mutable para ambos puede perder edición, confundir cancelar o dificultar rechazo. Duplicarlos es deliberado si se conoce cuál proviene de confirmación, cuál está editándose y cuándo se reemplaza o descarta cada uno.

El formulario puede conservar valores, touched/dirty, feedback de validación, envío pendiente y errores devueltos. No necesita vivir globalmente. model-view-viewmodel puede exponer ese estado y acciones; model-view-presenter puede coordinarlo mediante un contrato de View. ViewModel no equivale a todo estado de aplicación y Model de MVC no significa necesariamente store ni entidad persistida.

Validar localmente mejora interacción; la aplicación autoritativa sigue necesitando validar reglas pertinentes. Deshabilitar Save no impide solicitudes de otro canal. Un error de campo, rechazo de autorización, conflicto, fallo de red y resultado desconocido no deberían colapsarse irreflexivamente en un boolean. Modelar estados y transiciones permitidas puede ayudar sin exigir una máquina de estados universal.

Navegación también contiene estado

Ruta, identificador seleccionado, búsqueda, filtros y paginación pueden representarse en URL para compartir, guardar enlaces y recorrer historial. MDN, History API explica colaboración entre navegación y estado de una aplicación Web. No todo borrador ni dato sensible pertenece a esa representación.

Un filtro observable por toda la aplicación puede vivir en URL sin pertenecer a un store global. Definir qué ocurre al volver atrás, recargar o abrir un enlace evita mantener otra copia mutable sin reglas. El alcance de observación y el lugar de almacenamiento son decisiones separadas.

accessibility añade coherencia entre estado representado, semántica expuesta y continuidad de foco: cambiar selección o estado busy en un store no garantiza que el usuario lo pueda reconocer. internationalization conserva otro contexto cliente, como preferencia de locale y recursos vigentes; restaurarlo no debe reinterpretar moneda ni otros datos autoritativos. Estas responsabilidades requieren lifecycle explícito, sin imponer un único store global.

Almacenar, derivar y reconstruir

Si un valor se obtiene de entradas conocidas, otra copia mutable agrega trabajo para mantenerlo coherente. Un total visible puede derivarse de líneas y precios usados por la vista; productos filtrados, de colección y filtro. Esa derivación no vuelve autoritativo el importe que el backend debe confirmar para una compra.

React, Choosing the State Structure recomienda evitar redundancia y contradicciones en sus componentes. Redux, Deriving Data muestra derivación y selectors. Son apoyos concretos, no obligación de usar esas APIs. Derivación costosa puede justificar memoización: conservar un resultado calculado no cambia quién gobierna sus entradas.

Normalizar entidades mediante identidad puede reducir copias y simplificar cambios; reconstruir vistas introduce indirection. Redux documenta esa representación. Datos orientados a una vista también pueden ser útiles. No imponer normalización de bases a toda UI; identificar relaciones entre fuente local, proyección, borrador y cache derivada antes de declarar incorrecta cualquier duplicación.

Copias remotas y dos significados de ownership

data-ownership conserva autoridad semántica del sistema: Payments declara significado y cambios válidos del pago. El browser puede administrar una representación de PaymentStatus, sin poder convertir desconocido en autorizado. Acceso, almacenamiento y autoridad siguen separados, aunque esa copia sea la referencia común para todas las pantallas locales.

TanStack Query llama server state a datos remotos que el cliente consulta, actualiza y cachea, potencialmente modificados por otros actores. Su vocabulario de shared ownership no transfiere por sí mismo la autoridad de negocio definida en el Atlas. Aquí se distingue responsabilidad sobre una copia de autoridad sobre el hecho representado.

«Single source of truth» también necesita alcance. Puede designar una representación canónica local consumida por varias vistas, mientras un backend sigue siendo autoridad comercial. No significa que un Redux store o cache cliente reemplace a ese owner. Nombrar el objeto Product 42 ayuda a dirigir cambios, pero su identidad cliente tampoco tiene que ser la clave física de una base.

Vigencia, invalidación y refetch

Una cache tiene fuente, identidad, vigencia, política de invalidación, expulsión y comportamiento ante errores. La copia puede quedar stale cuando cambia el backend sin que el cliente lo observe. Descripción de producto, disponibilidad y autorización de pago pueden necesitar compromisos distintos; no hay TTL universal.

Los defaults de TanStack Query separan freshness, refetch e inactividad. Aquí se usan para mostrar decisiones distintas, sin adoptar sus intervalos. Invalidar por tiempo, mutación, señal servidor, navegación o refresh exige explicar qué observación vuelve insuficiente la copia. Refetch puede reemplazarla, pero más peticiones también cuestan red, carga, cambios visuales y carreras.

En Commerce, un precio cacheado puede seguir mostrándose tras un cambio remoto. La compra necesita validación por la capacidad autoritativa, no confianza automática en el último valor visible. Una notificación servidor puede actualizar o invalidar la representación; WebSockets o SSE no constituyen por sí mismos una arquitectura de estado ni resuelven conflictos.

Optimismo y confirmación en Commerce

Un usuario cambia cantidad del carrito de uno a dos. Una representación optimista puede mostrar dos antes de confirmar; si Inventory rechaza por stock, hay que reconciliar y explicar el resultado. TanStack Query documenta actualizaciones optimistas sobre UI o cache. No convierten esa expectativa en autoridad de Inventory ni prescriben una política para todo dominio.

Esperar confirmación puede simplificar el significado de lo mostrado, con mayor demora percibida; también pueden combinarse feedback inmediato y resultado confirmado posterior. Revertir ciegamente un snapshot puede pisar una mutación más reciente. Identificar qué intento produjo cada expectativa y qué estado se reconcilia conserva las diferencias importantes.

Pay puede llevar la UI a Submitting. Si ocurre timeout, el resultado remoto puede ser desconocido: no corresponde inventar Failed o Authorized por la mera espera local. idempotency ayuda a razonar sobre repetición cuando el contrato lo permite. El estado pendiente y su incertidumbre deben sobrevivir conceptualmente a una elección de biblioteca.

Concurrencia y lifecycle de peticiones

Búsqueda «a» seguida de «ab» puede recibir respuestas en orden inverso. Aplicar la primera al llegar después puede reemplazar resultados pertinentes con datos viejos. Identidad de petición, aceptación de la última intención, cancelación o versiones son alternativas según contrato, no un mecanismo universal. UDF organiza propagación; no elimina esa carrera.

Loading, éxito, error o refresh describen información relevante del trabajo, no solo contenido recibido. Una vista puede mostrar datos previos y error de actualización simultáneamente. También importan navegación, mutaciones concurrentes y snapshots capturados antes de otro cambio. Cancelar o ignorar trabajo cliente no garantiza cancelar una operación comercial que el servidor ya ejecutó.

Persistencia y duración real

Persistir puede hacer sobrevivir información a reload o reinicio. MDN distingue los alcances de Web Storage; otras plataformas ofrecen mecanismos propios. Elegir storage no decide qué debe restaurarse ni si sigue siendo válido. Lo conservado puede sobrevivir a versión de código, schema, sesión, identidad o permisos.

Prever versión, migración, invalidación o reset cuando cambie estructura o significado. data-migration aporta preguntas de transformación, con un alcance aquí acotado al cliente. Restaurar datos antiguos sin comprobar contexto puede recuperar un borrador de otra cuenta o una copia incompatible. Revisar creación, refresh, descarte y cleanup al cerrar una feature, navegar o finalizar sesión.

Persistencia local no equivale a almacenamiento seguro. OWASP señala riesgos de datos sensibles en almacenamiento Web. Delimitar qué puede conservarse y bajo qué condiciones, sin convertir este canonical en gestión de tokens. Suscripciones, listeners y caches también necesitan terminar para no retener estado y recursos abandonados.

Estado inicial y composición de presentación

SSR puede entregar representación y datos serializados para inicializar el cliente. Aclarar contexto, vigencia y refetch: una carga duplicada puede agregar espera o sobrescribir una edición. Hydration puede encontrar diferencias de datos o entorno; rendering-strategies conserva su explicación completa. Activar UI no demuestra sincronizar todas las copias.

React describe preservación y reset según su identidad y posición de componentes; Android distingue state holders y lifecycle. Son reglas y categorías de sus plataformas, no obligaciones universales. Store, state holder, UI state y application state deben leerse con su contexto.

Límites y criterio de elección

Varias pestañas, ventanas o dispositivos pueden conservar copias divergentes. synchronization desarrolla intercambio, progreso y reconciliación; offline-first, utilidad bajo conectividad ausente o intermitente. Cache o persistencia no equivalen a esos enfoques. mobile-architecture añade restricciones de plataforma: proceso, pantalla, sesión y workflow pueden tener duraciones diferentes, por lo que restaurar estado exige decidir qué información debe sobrevivir. micro-frontends examina composición y autonomía de entrega, donde compartir estado puede vincular partes; backend-for-frontend adapta capacidades desde el servidor, sin administrar automáticamente estado de UI ni transferir autoridad comercial.

Un evento es entrada o noticia, no necesariamente estado que deba conservarse indefinidamente. Tampoco una biblioteca es madurez arquitectónica: mecanismos incorporados pueden bastar. Examinar ownership confuso, consumidores distantes, coordinación repetida, efectos y duración, sin umbrales numéricos. accidental-complexity permite discutir estructura añadida que ayuda o estorba.

testability requiere probar también efectos, cache, restauración, bindings y backend; herramientas de inspección no demuestran una arquitectura correcta. web-performance examina cómo alcance de invalidación, recomputación y refresh afecta trabajo cliente, sin deducir rendimiento de la biblioteca de estado. El criterio es poder explicar quién posee cada información, dónde vive, cuánto dura, cómo cambia y qué evidencia la confirma; frontend-and-client-architecture conecta esas preguntas sin absorber los conceptos vecinos.