Estado del ámbito por vida útil: Cuándo un React Portal realmente necesita una tienda global

Los equipos que desarrollan portales internos suelen comenzar la discusión sobre el estado con “Redux o Zustand?”. Una pregunta inicial más útil es determinar qué partes del estado realmente necesitan ser globales. Este artículo muestra cómo clasificar el estado de los portales según quien lo gestiona y cuánto tiempo debe permanecer activo, por qué almacenar estado de corta duración en un almacén global genera una serie constante de errores de limpieza, y cuándo es adecuado utilizar una biblioteca global.

La mayor parte del estado de los portales es de corta duración

Los portales suelen ser colecciones de flujos de trabajo independientes. Un usuario abre una página, busca o edita algo, completa la tarea y pasa a otra sección de la aplicación. Los valores de los formularios, los filtros, las filas de tabla seleccionadas, la pestaña activa y si hay un modal abierto pertenecen todos a esa página o flujo de trabajo. Rara vez es necesario que persistan en varias rutas no relacionadas.

Solo un pequeño conjunto de datos es realmente aplicativo en su totalidad:

• el usuario conectado;
• el estado de autenticación y los permisos;
• la organización o inquilino actual;
• las preferencias de tema e idioma.

Casi todo lo demás debería permanecer cerca de la función que lo genera.

Los almacenes globales convierten el ciclo de vida en una tarea de limpieza

Al guardar el estado temporal en Redux, Zustand, MobX o cualquier otro almacén global, este sobrevive a la pantalla que lo creó. Ahora se necesita código adicional para restablecerlo al navegar, después de enviar datos, al cerrar sesión, cuando cambia el inquilino y en cualquier otra ruta de salida. Si se omite alguna ruta, el usuario regresa a una pantalla que muestra filtros obsoletos, selecciones antiguas o valores de formularios parcialmente completados de una visita anterior. Estos errores son difíciles de reproducir porque dependen de la secuencia exacta de pantallas que visitó el usuario.

La regla general es sencilla: si el estado global tiene que limpiarse constantemente para que se comporte como un estado local, probablemente debería haber sido local desde el principio.

Elija el alcance más reducido que sea adecuado

Associe cada parte del estado con la herramienta más específica que abarque todo su ciclo de vida:

• estado del componente para el comportamiento de la interfaz que concierne a un único componente;
• React Context para el estado compartido entre una función o un grupo de rutas relacionadas;
• parámetros de búsqueda en la URL para filtros, paginación y otro estado de navegación, lo que también permite compartir vistas y que estas sobrevivan a un recargue;
• una biblioteca de estado del servidor como TanStack Query para los datos obtenidos desde el backend, ya que su función es el caché y la invalidación, no la del almacén de estado;
• un almacén global únicamente para el estado del cliente que sea realmente aplicable a toda la aplicación.

El contexto a nivel de ruta merece mención especial. Cuando se coloca un proveedor alrededor de un grupo de rutas, dejar ese grupo sin montar desmonta el proveedor y su estado desaparece automáticamente. El ciclo de vida de los componentes de React se encarga de la limpieza que de otro modo tendrías que realizar manualmente. Si lo que te lleva a utilizar un almacén de estado es realmente la necesidad de pasar propiedades a través de muchas capas, ese es un problema distinto con soluciones más sencillas, abordado en por qué el paso de propiedades a través de múltiples capas no es motivo para instalar Redux o Zustand.

Cuando un almacén global tiene sentido

Redux, Zustand y bibliotecas similares son la opción adecuada cuando se desea que el estado persista intencionalmente en pantallas no relacionadas. Los casos típicos incluyen:

• carrusesels de compras;
• flujos de pago complejos que abarcan varias páginas;
• borradores que deben mantenerse.

• Aplicaciones enfocadas en modo sin conexión;
• Sistemas de mensajería o notificaciones en toda la aplicación;
• Funciones de deshacer y rehacer;
• Características en tiempo real donde es necesario coordinar el estado del cliente;
• Flujos de trabajo complejos con muchas transiciones de estado interdependientes.

En estas situaciones, el estado centralizado resuelve un problema real en lugar de crear uno.

Puntos clave

• Decida quién será el responsable y cuál será la vida útil del estado antes de elegir cualquier biblioteca.
• El estado que pertenece a un único flujo de trabajo debería desaparecer junto con ese flujo, idealmente mediante su desmontaje en lugar de reinicios manuales.
• Mantenga los datos del servidor en una biblioteca de consultas y el estado de navegación en la URL.
• Reserve un almacén global para el estado que toda la aplicación comparte intencionalmente a lo largo del tiempo; saber cuándo no usarlo forma parte de una buena arquitectura.

Lecturas relacionadas

• Capas de estado en una app streaming de React: Contexto, Redux Toolkit y RTK Query — Sigue el desarrollo de una interfaz de transmisión de video desde el uso de prop drilling hasta proveedores anidados, pasando por las slices de Redux Toolkit y RTK Query, y aprende qué tipo de estado pertenece a cada herramienta.
• Prop drilling no es una razón para instalar Redux o Zustand — Prueba cuatro motivos comunes para añadir una biblioteca de estado en código React funcional: el uso del contexto para resolver problemas de prop drilling, useState, useSyncExternalStore y el costo de volver a renderizar del contexto.

Medición de los gestores de estado de React: Comparación de las cantidades de renderizaciones y el tamaño del paquete comprimido — Una aplicación de carrito construida con ocho patrones de estado de React, analizada en cuanto a renderizaciones innecesarias y tamaño del paquete comprimido, y lo que las cifras revelan sobre Zustand, Valtio y Context.