Persistencia selectiva

Llegas al final del nivel con las herramientas para persistir, hidratar, sobrevivir al servidor y funcionar sin red, y justo aquí aparece la tentación más peligrosa: usarlas para todo. Es cómodo escribir una línea que serializa el store completo y creer el trabajo hecho, pero esa línea siembra dos problemas que estallarán meses después, cuando ya nadie recuerde haberla escrito. El primero es de seguridad y alcance: no todo estado debe tocar el disco, y algunos fragmentos —los tokens, los datos personales, el caché que caduca— hacen daño precisamente por estar guardados. El segundo es de tiempo: el instante en que despliegas persistencia, el objeto que escribes deja de ser tuyo y pasa a vivir en los discos de tus usuarios, congelado con la forma que tu código tenía ese día. Tu código seguirá evolucionando; el objeto guardado, no. Y cuando la versión de mañana lea la forma de hoy, o peor, la de hace un año, o falla con elegancia o corrompe la experiencia. La persistencia madura no es, por tanto, guardar más: es guardar menos y con un contrato de versión que te permita cambiar sin romper a quien ya confió sus datos a tu formato.

Lista blanca, nunca volcado total

La regla de oro de qué persistir es la misma que la de los permisos: denegar por defecto y permitir por excepción. En lugar de guardar el store entero y excluir lo problemático —una lista negra que olvidará el próximo campo peligroso que añadas—, declara explícitamente el puñado de campos que merecen disco. Los middlewares lo llaman partialize: una función que recibe el estado completo y devuelve solo la porción a persistir.

// Lista blanca: solo lo que el usuario esperaria reencontrar.
const persistir = (estado: Estado) => ({
  tema: estado.tema,
  idioma: estado.idioma,
  borrador: estado.borrador,
  // NO: token, usuario.datosSensibles, cacheServidor, totalesDerivados
})

Lo que queda fuera no es arbitrario. Los tokens y secretos encabezan la exclusión por una razón que va más allá de la higiene, y la desarrollamos abajo. El caché del servidor se excluye porque su verdad vive remota y guardarlo local solo crea copias rancias que contradicen a la API al volver. Los datos derivados se excluyen porque son recalculables y persistirlos es guardar una respuesta que puede quedar desalineada con la pregunta. Y el estado efímero de interfaz se excluye porque nadie echa de menos un modal que estaba abierto.

Los secretos no son el único dato que conviene mantener fuera del disco por razones ajenas a lo técnico. Los datos personales identificables —nombres, correos, ubicaciones, historiales— persistidos en el navegador amplían la superficie de exposición y caen bajo normativas como el RGPD, que preguntan por qué guardas lo que guardas y durante cuánto tiempo. La persistencia selectiva no es solo una optimización de rendimiento: es también minimización de datos, un principio que reduce a la vez tu riesgo de seguridad y tu carga de cumplimiento legal. Guardar menos es, casi siempre, guardar mejor.

El estado guardado es un formato con contrato

Aquí está la idea que cambia la forma de pensar la persistencia. En el momento en que tu app escribe en el disco de un usuario, has creado un formato de datos, y ese formato es ahora tan público y tan inmutable como una API que hubieras publicado. Está congelado con la forma exacta que tu estado tenía el día del despliegue, y permanecerá así en el navegador de ese usuario hasta que él vuelva —mañana, o dentro de un año— con una versión de tu app que quizá ya no reconoce esa forma.

La fusión con valores por defecto de la lección dos cubre el caso benigno: campos nuevos que no existían. Pero no cubre los cambios estructurales, que son los frecuentes en un proyecto vivo: renombrar un campo, partir uno en dos, cambiar el tipo de un valor, reorganizar un objeto anidado. Ante esos cambios, la fusión no basta; el dato viejo llega con una forma que el código nuevo malinterpreta, y ninguna cantidad de spread lo arregla.

Hay una asimetría cruel en este contrato: tú controlas cuándo cambias el código, pero no cuándo el usuario vuelve. Puedes desplegar diez versiones en un mes, pero un usuario que abrió la app en enero y regresa en diciembre saltará de la forma uno a la once de golpe, sin pasar por las intermedias en el tiempo real. Tu lógica de lectura tiene que estar preparada para recibir cualquier forma pasada, no solo la inmediatamente anterior, y esa es precisamente la razón por la que la migración no puede ser un único condicional sino una cadena capaz de cubrir todo el historial de un salto.

Versionado y migración

La solución es la misma que usan las bases de datos desde hace décadas: sella cada objeto persistido con un número de versión y, al rehidratar, compáralo con la versión actual del código. Si coinciden, usa el dato tal cual. Si el guardado es más viejo, pásalo por una cadena de migraciones que lo transforme paso a paso hasta la forma actual. Cada migración es una función pura de una versión a la siguiente.

const VERSION = 3
const migraciones: Record<number, (e: any) => any> = {
  1: (e) => ({ ...e, idioma: e.lang, lang: undefined }),   // renombrar campo
  2: (e) => ({ ...e, tema: e.oscuro ? 'oscuro' : 'claro' }), // cambiar tipo
  3: (e) => ({ ...e, borrador: { texto: e.borrador ?? '' } }) // partir en objeto
}

function migrar(blob: { version: number; estado: any }) {
  let { version, estado } = blob
  while (version < VERSION) {          // aplica en cadena: 1 -> 2 -> 3
    version++
    estado = migraciones[version](estado)
  }
  return estado
}

El caso que más se olvida es el del blob que no puedes migrar: una versión desconocida, una guardada por un despliegue futuro al que el usuario hizo rollback, o un dato corrupto. La respuesta correcta no es lanzar una excepción que rompe el arranque, sino el descarte seguro: si no sabes leer el formato, ignóralo y arranca con los valores por defecto. Perder una preferencia es una molestia; un arranque que revienta por un blob ilegible es un producto roto.

Nota un detalle fácil de pasar por alto: los blobs escritos por tu primera versión, antes de que existiera el versionado, no llevan número de versión. Trátalos como versión cero y haz que la ausencia del campo equivalga al arranque del historial de migraciones. Ese caso, el de los usuarios más antiguos, es precisamente el que más migraciones tendrá que atravesar y el que más fácil se olvida al probar.

flowchart TD
L[leer blob guardado] --> V{version del blob}
V -->|igual a la actual| U[usar tal cual]
V -->|menor| M[aplicar migraciones en cadena]
V -->|desconocida o mayor| R[descartar y reiniciar seguro]
M --> U
style U fill:#a6e3a1,color:#11111b
style R fill:#f9e2af,color:#11111b

Probar el contrato y sincronizar pestañas

Si el estado guardado es un contrato, las migraciones son cláusulas que hay que verificar, no código que se escribe y se olvida. Una migración rota no falla en tu máquina, donde ya tienes la forma nueva: falla meses después, en el navegador de un usuario que vuelve con la forma vieja, y para entonces nadie recuerda el cambio que la provocó. La defensa es guardar blobs reales de versiones antiguas como fixtures y afirmar en un test que la migración lleva cada uno hasta la forma actual sin perder datos.

// Guarda blobs reales de versiones pasadas y afirma que migran bien.
test('migra v1 hasta la version actual sin perder datos', () => {
  const v1 = { version: 1, estado: { lang: 'es', oscuro: true, borrador: 'hola' } }
  const actual = migrar(v1)
  expect(actual.idioma).toBe('es')                   // renombrado en v1 -> v2
  expect(actual.tema).toBe('oscuro')                 // tipo cambiado en v2 -> v3
  expect(actual.borrador).toEqual({ texto: 'hola' }) // partido en v3
})

De ahí se sigue una regla de higiene inflexible: una migración ya desplegada es inmutable. En cuanto sale a producción se ha ejecutado sobre discos que no controlas, y editarla cambia el resultado para quien aún no la había corrido, desalineando a unos usuarios con otros. Si te equivocaste, no corrijas la vieja: añade una migración nueva que repare. El historial de migraciones crece, nunca se reescribe, exactamente como el de una base de datos.

Queda un frente más, el de las pestañas. Cuando una pestaña migra y reescribe el blob, otras pestañas abiertas siguen con el estado viejo en memoria, ajenas al cambio. El evento storage vuelve a ser la herramienta: escúchalo para detectar que otra pestaña reescribió el almacén y decide de forma explícita qué hacer —recargar, fusionar o avisar—, porque ignorarlo deja conviviendo dos verdades en el mismo navegador.

Un cambio que casi nadie trata como migración y lo es: quitar un campo de la lista blanca. El código nuevo deja de escribirlo, pero los blobs viejos aún lo contienen, y ese dato huérfano se seguirá cargando e hidratando hasta que alguien lo limpie. Si el campo era sensible, sigue en el disco pese a que creíste haberlo eliminado. Retirar un campo persistido merece una migración que lo borre de forma explícita, no solo su desaparición del código.

// Retirar un campo del disco es tambien una migracion:
4: (e) => { const { tokenViejo, ...resto } = e; return resto } // borra el huerfano