El viaje del estado

Todo lo que has aprendido sobre estado hasta aquí asumía en silencio una comodidad enorme: que el estado vive en un único proceso, en una única memoria, y que quien lo escribe y quien lo lee comparten el mismo montón de objetos. El renderizado en servidor rompe esa premisa de raíz. Hay dos ejecuciones del mismo código, en dos máquinas distintas, separadas por decenas de milisegundos y por un protocolo que solo sabe transportar texto. El servidor consulta la base de datos, calcula el estado inicial, lo usa para producir un HTML completo y muere. El navegador recibe ese HTML ya pintado, arranca el mismo código y descubre que su estado está vacío: no heredó nada, porque los objetos del servidor no viajan, se destruyen con el proceso que los creó. Si nadie hace nada, el cliente vuelve a pedir a la red exactamente los datos que el servidor ya tenía en la mano, y el usuario ve la pantalla llenarse, vaciarse y volver a llenarse. La solución tiene un nombre técnico preciso y una mecánica que conviene entender antes que cualquier librería: el servidor deshidrata su estado a una forma transportable, lo escribe dentro del propio documento, y el cliente lo hidrata para arrancar ya poblado. Esta lección es el mapa de ese viaje.

Dos ejecuciones separadas por un abismo

La intuición equivocada más común es imaginar el SSR como una continuación: el servidor empieza a renderizar y el cliente termina. No hay continuación. Hay dos ejecuciones independientes del mismo código fuente sobre dos entornos distintos, y lo único que las conecta es el documento que una escribe y la otra lee. El servidor no puede pasarle una referencia a un objeto al cliente, igual que un proceso de Unix no puede pasarle un puntero a otro: la dirección de memoria no significa nada al otro lado.

Esto convierte el problema en uno perfectamente conocido en sistemas distribuidos. Cuando dos procesos que no comparten memoria necesitan intercambiar una estructura, el emisor la traduce a una secuencia de bytes autocontenida y el receptor la reconstruye. Eso es serialización, y arrastra sus tres impuestos clásicos: pérdida de identidad, pérdida de comportamiento y pérdida de tipos que el formato no contempla.

Conviene además desmontar una segunda intuición engañosa, la de que el HTML ya contiene el estado y bastaría con leerlo del DOM. El HTML contiene una proyección visual del estado, no el estado: contiene el nombre impreso, no el registro del que salió; contiene la lista pintada, no el array con sus identificadores, sus banderas y los campos que la vista no muestra. Reconstruir el estado leyendo el marcado es un ejercicio de arqueología condenado a perder información, y por eso todas las soluciones serias del ecosistema transportan el estado aparte, en paralelo al marcado que produjo.

Sin ese puente, el cliente arranca con el estado por defecto que declara el código, no con el que el servidor calculó. El HTML muestra los datos correctos, pero el estado que gobierna ese HTML está vacío. La discrepancia se resuelve del peor modo posible: el cliente pide de nuevo a la red lo que ya estaba en la página, y el usuario paga con un parpadeo y una petición redundante lo que ya se había hecho.

flowchart TD
S[servidor consulta datos y calcula estado] --> D[dehydrate a estructura plana]
D --> J[serialize a texto seguro]
J --> H[HTML con el estado incrustado]
H --> N[red]
N --> P[cliente parsea el texto]
P --> R[hydrate: el store arranca poblado]
R --> OK[sin peticion redundante y sin parpadeo]
style OK fill:#a6e3a1,color:#11111b

Deshidratar, serializar, transportar, hidratar

Conviene separar cuatro verbos que la conversación cotidiana mezcla, porque cada uno resuelve un problema distinto y falla de manera distinta.

El lado del servidor es breve y su única sutileza es el escapado. Un dato de usuario que contenga la secuencia de cierre de la etiqueta script cerraría el bloque antes de tiempo y todo lo que siguiera se interpretaría como marcado. Escapar el carácter de apertura de etiqueta a su forma unicode elimina el problema sin alterar el valor.

// SERVIDOR: calcular, deshidratar, serializar e inyectar
const estado = await cargarEstadoInicial(peticion)

const json = JSON.stringify(estado)
  .replace(/</g, '\\u003c')   // evita el cierre prematuro de script
  .replace(/\u2028/g, '\\u2028') // separadores de linea invisibles
  .replace(/\u2029/g, '\\u2029')

const marca = `<script id="estado" type="application/json">${json}</script>`

Usar una etiqueta script con tipo application/json en lugar de asignar el valor a una propiedad global no es una preferencia estética. Un tipo desconocido impide que el navegador ejecute el contenido, de modo que un fallo de escapado degrada a error de análisis en vez de a ejecución de código ajeno; además el bloque queda inerte, sin coste de compilación, y su contenido puede leerse como texto plano cuando haga falta depurarlo.

El lado del cliente es su reverso exacto, y merece una regla que se olvida a menudo: leer el nodo una sola vez, al arrancar, y nunca volver a consultarlo. Ese texto es una fotografía del instante en que el servidor respondió; releerlo más tarde significa resucitar datos ya caducados.

// CLIENTE: leer, parsear e hidratar una unica vez
const nodo = document.getElementById('estado')
const inicial = nodo ? JSON.parse(nodo.textContent ?? '{}') : {}

const store = crearStore(inicial) // arranca poblado, no vacio

Lo que no sobrevive al viaje

JSON reconoce seis cosas: objetos, listas, cadenas, números, booleanos y el valor nulo. Todo lo demás se degrada en silencio, y el silencio es justamente lo peligroso, porque el error no aparece al serializar sino mucho después, cuando alguien llama a un método que ya no existe.

Una fecha se convierte en cadena y pierde su interfaz. Un Map o un Set se convierten en objeto vacío o en algo irreconocible. Una instancia de clase pierde su prototipo y llega como objeto plano. Una función desaparece de la salida sin dejar rastro. Un valor indefinido se elimina de los objetos y se convierte en nulo dentro de las listas. Y las referencias compartidas se duplican: dos propiedades que apuntaban al mismo objeto llegan como dos objetos distintos, mientras que un ciclo directamente lanza una excepción.

const original = {
  fecha: new Date(),
  etiquetas: new Set(['a', 'b']),
  saludar: () => 'hola',
  vacio: undefined,
}

const copia = JSON.parse(JSON.stringify(original))
// copia.fecha      -> cadena, ya no tiene metodos de fecha
// copia.etiquetas  -> objeto vacio, el contenido se perdio
// copia.saludar    -> no existe, la clave desaparecio
// copia.vacio      -> no existe

Hay dos respuestas legítimas y conviene elegir a conciencia. La primera es empobrecer el dato en origen: deshidratar solo tipos primitivos, guardar las fechas como cadenas normalizadas y las colecciones como listas, y reconstruir la riqueza en el cliente al hidratar. La segunda es usar un serializador enriquecido que codifique los tipos perdidos y sepa restaurarlos al otro lado, al precio de un poco más de peso y de una dependencia compartida por ambos entornos.

La primera opción escala mejor de lo que parece y tiene una virtud que rara vez se menciona: obliga a definir un contrato explícito entre servidor y cliente. Si el estado deshidratado solo contiene primitivos, listas y objetos planos, entonces está descrito por completo por su forma, es validable con un esquema y es estable frente a cambios de librería. Los serializadores enriquecidos son cómodos, pero acoplan ambos extremos a una misma versión de una misma herramienta y esconden dentro de la carga útil una gramática privada que nadie más entiende.

// Empobrecer en origen y reconstruir al llegar: contrato explicito
type PerfilPlano = { id: string; alta: string; etiquetas: string[] }

const aPlano = (p: Perfil): PerfilPlano => ({
  id: p.id,
  alta: p.alta.toISOString(),
  etiquetas: [...p.etiquetas],
})

const aRico = (p: PerfilPlano): Perfil => ({
  id: p.id,
  alta: new Date(p.alta),
  etiquetas: new Set(p.etiquetas),
})