La rehidratación: la ventana entre el primer pintado y el estado real

Rehidratar es el instante en que un estado escrito por una ejecución anterior entra en el store de la ejecución actual, y ese instante nunca es el instante cero. Siempre hay un antes: un tramo en el que la aplicación existe, tiene estado, se renderiza y responde, pero el estado que tiene es el que declara el código y no el que el usuario dejó. Esa ventana puede durar un fotograma o medio segundo, y su duración importa menos que su existencia, porque cualquier decisión visible que tu interfaz tome dentro de ella tendrá que deshacerse en cuanto la ventana se cierre. El usuario percibe ese deshacer como un fallo de calidad —un parpadeo, un salto, una redirección absurda— y no tiene forma de saber que está viendo la costura entre dos fuentes de verdad. Entender la ventana es entender por qué la persistencia, que parece un problema de almacenamiento, es en realidad un problema de orquestación temporal.

Por qué existe la ventana

El almacenamiento local del navegador es síncrono, así que la intuición dice que el estado guardado debería estar disponible antes del primer render y la ventana no debería existir. Es cierto solo en el caso más favorable, y conviene ver por qué se rompe en todos los demás. Se rompe cuando el almacén es asíncrono, que es lo normal fuera de la web más simple: una base de datos indexada, un almacén nativo en móvil o cualquier cosa que cruce un proceso devuelve una promesa, y la lectura de una promesa no puede terminar antes del primer render por definición.

Se rompe también cuando la herramienta decide tratar la lectura como asíncrona por uniformidad, que es lo que hace redux-persist: su ciclo despacha una acción de arranque, encola la lectura y despacha la rehidratación después, de modo que hay al menos una actualización de por medio aunque el dato estuviera disponible al instante. Y se rompe, por último, cuando el código se parte en fragmentos: el trozo que contiene el store puede llegar más tarde que el trozo que pinta la cabecera, y entonces la ventana no la abre el almacén sino la red.

sequenceDiagram
participant N as navegador
participant A as aplicacion
participant S as almacen
N->>A: ejecuta el arranque
A->>A: crea el store con el estado del codigo
A->>N: primer pintado con tema claro
A->>S: lee la clave guardada
S-->>A: devuelve tema oscuro
A->>A: funde y actualiza el store
A->>N: segundo pintado con tema oscuro
Note over N,A: la ventana es todo lo que hay entre los dos pintados

Las tres formas del parpadeo

La primera y más conocida es el destello del tema equivocado: la página aparece clara durante uno o dos fotogramas y se vuelve oscura. Es visualmente agresiva, ocurre en cada carga y en pantallas oscuras resulta físicamente molesta. La segunda es el vacío que se llena de golpe: el carrito muestra cero artículos, la barra lateral aparece desplegada, la tabla muestra sus columnas por defecto, y todo se reordena un instante después provocando un salto de disposición que además penaliza las métricas de estabilidad visual.

La tercera es la más grave porque no es cosmética: el falso deslogueo. Si el guardián de rutas pregunta por un dato de sesión que todavía no ha llegado, concluye que no hay usuario y redirige a la pantalla de acceso; medio segundo después el dato llega, el guardián cambia de opinión y devuelve al usuario a donde estaba. El resultado es una navegación fantasma que además puede destruir estado no guardado del formulario que el usuario tenía abierto.

Hay una cuarta manifestación menos visible y más insidiosa que conviene nombrar: el efecto que se dispara dentro de la ventana. Si un componente lanza una petición al montarse usando un filtro que todavía no ha llegado del almacén, la petición sale con el filtro por defecto, el servidor responde, la respuesta se pinta, y un instante después llega el filtro guardado y todo se repite. El usuario ve dos cargas donde debería haber una, y el servidor recibe el doble de tráfico del necesario en cada arranque de cada sesión.

Las tres familias de solución

La primera familia retiene el pintado hasta que el estado guardado ha llegado. En Redux se hace con la compuerta que acompaña a la librería; en Zustand, con una bandera que consulta si la hidratación terminó. Es la solución más sencilla de razonar y la más fácil de aplicar mal, porque quien la descubre tiende a envolver la aplicación entera y convierte un parpadeo de dos fotogramas en una pantalla en blanco de medio segundo, que es un empeoramiento medible del tiempo de pintado del contenido principal.

// Zustand: una bandera que distingue los tres estados posibles.
function useHidratado() {
  const [listo, setListo] = useState(usePreferencias.persist.hasHydrated())
  useEffect(() => {
    const fin = usePreferencias.persist.onFinishHydration(() => setListo(true))
    return fin
  }, [])
  return listo
}

// Redux: la compuerta acepta un contenido de espera y una llamada al terminar.
const raiz = h(Provider, { store }, [
  h(PersistGate, { persistor, loading: null }, [h(App)]),
])

// El equivalente sin compuerta: observar el estado del persistor a mano.
persistor.subscribe(() => {
  const { bootstrapped } = persistor.getState()
  if (bootstrapped) marcarListo()
})

La segunda familia es la misma técnica aplicada con bisturí: no se retiene la aplicación, se retiene únicamente el subárbol cuyo aspecto depende del dato guardado, y mientras tanto se reserva su espacio con un contenedor de las mismas dimensiones. Se conserva el pintado inmediato de todo lo que no depende del almacén, se elimina el salto de disposición y el usuario ve una carga honesta en lugar de una respuesta falsa. Es la opción correcta para carritos, paneles plegables, tablas con columnas configurables y prácticamente todo lo que no sea el tema.

// Retener solo lo que depende del dato, y reservar su hueco.
function Carrito() {
  const listo = useHidratado()
  const lineas = usePreferencias((s) => s.lineas)
  // el hueco tiene las mismas dimensiones que el contenido final
  if (!listo) return h('div', { className: 'h-12 w-24 animate-pulse rounded' })
  return h(Contador, { n: lineas.length })
}

// Fragmento bloqueante en la cabecera: ocurre antes del primer pintado.
const t = localStorage.getItem('tema')
const oscuro = t ? JSON.parse(t) === 'oscuro' : matchMedia('(prefers-color-scheme: dark)').matches
document.documentElement.dataset.tema = oscuro ? 'oscuro' : 'claro'

Merece la pena insistir en el detalle del hueco reservado, porque es lo que separa una carga honesta de un salto molesto. Si el contenido definitivo ocupa cuarenta y ocho píxeles de alto y el contenido provisional ocupa cero, el resto de la página se desplazará cuando llegue el dato, y ese desplazamiento cuenta como inestabilidad visual en cualquier medición de calidad. Reservar el espacio exacto convierte la ventana en un detalle imperceptible: algo aparece donde ya había sitio para ello, que es como el usuario espera que se comporte una interfaz.

// Un unico punto donde se decide que se pinta en cada uno de los tres estados.
type Fase = 'desconocido' | 'hidratado' | 'vacio'

function fase(listo: boolean, hay: boolean): Fase {
  if (!listo) return 'desconocido'
  return hay ? 'hidratado' : 'vacio'
}

La tercera familia elimina el problema por diseño en lugar de gestionarlo: hacer que la decisión no dependa del dato persistido. El caso claro es la autenticación. Un guardián de rutas nunca debería derivar su decisión de un valor rehidratado del almacén del navegador, porque ese valor no es autoridad —el servidor puede haber revocado la sesión mientras el usuario no estaba— y porque llega tarde. Si la decisión la toma el servidor, o un estado de sesión que arranca explícitamente en desconocido y solo se resuelve tras verificar, el falso deslogueo desaparece sin necesidad de compuertas.