atomFamily y atomWithStorage: familias y persistencia

El núcleo de Jotai es deliberadamente diminuto: un constructor de átomos y tres hooks. Todo lo demás vive en utilidades opcionales que se pagan solo si se usan, y dos de ellas resuelven problemas que aparecen en casi cualquier aplicación seria. atomFamily responde a la pregunta de qué hacer cuando el número de átomos no se conoce al escribir el código, porque depende de datos: mil filas, doscientos campos generados, una celda por coordenada. atomWithStorage responde a la de cómo sobrevivir a una recarga sin escribir la coreografía de lectura, escritura y sincronización entre pestañas. Ambas son sencillas de usar y traicioneras si se ignoran sus contrapartidas, que son respectivamente el ciclo de vida y la hidratación.

Un átomo por identidad

atomFamily recibe una fábrica y devuelve una función que, dada una clave, produce el átomo correspondiente. La pieza esencial es la memoización: invocarla dos veces con la misma clave devuelve exactamente el mismo objeto átomo, lo que preserva la identidad referencial de la que depende todo el modelo. Sin esa memoización cada renderizado fabricaría átomos nuevos y el estado se perdería en cada ciclo.

import { atom } from 'jotai'
import { atomFamily } from 'jotai/utils'

const celdaAtom = atomFamily((id: string) => atom(''))

// la fabrica puede producir derivados: cada celda calculada lee otras por su id
const celdaCalculadaAtom = atomFamily((id: string) =>
  atom((get) => evaluarFormula(get(celdaAtom(id)))),
)

// claves compuestas: hace falta un comparador porque la identidad de objeto no sirve
const puntoAtom = atomFamily(
  ({ fila, col }: { fila: number; col: number }) => atom(0),
  (a, b) => a.fila === b.fila && a.col === b.col,
)

Nótese que la fábrica se invoca una sola vez por clave y que su resultado queda fijado. Cualquier valor capturado en el cuerpo de la fábrica —una configuración leída al vuelo, una fecha, un parámetro externo— quedará congelado en el átomo resultante y no se actualizará nunca, por mucho que la fuente original cambie después. Las dependencias que deban seguir vivas tienen que entrar por donde entran siempre en este modelo: leyéndolas desde dentro de una función de derivación, no capturándolas por cierre.

La clave compuesta merece una nota. Como la memoización se hace por identidad, un objeto literal usado como clave produciría un átomo nuevo en cada llamada. El segundo argumento de atomFamily es un comparador que sustituye la identidad por igualdad estructural, y sin él una familia parametrizada por objetos es una fuga garantizada. Con claves primitivas —cadenas o números— el comparador no hace falta.

Conviene también distinguir la familia de una utilidad vecina con la que se confunde a menudo. Descomponer un átomo de lista en un átomo por elemento parte de una colección existente y la reparte; la familia parte de una clave y fabrica bajo demanda, sin que exista ninguna lista previa. La primera sirve cuando los datos llegan juntos y el objetivo es aislar el renderizado; la segunda, cuando el conjunto de identidades es abierto y los elementos aparecen y desaparecen por su cuenta.

El efecto arquitectónico de la familia es que el aislamiento deja de ser algo que se construye y pasa a ser la topología por defecto. En un store central, mil filas viven en un mismo array y evitar que editar una re-renderice a las novecientas noventa y nueve restantes exige selectores memoizados por índice y comparadores cuidadosos. Con una familia, mil filas son mil átomos independientes con mil suscripciones independientes, y el aislamiento no cuesta trabajo porque es consecuencia de la estructura.

flowchart TD
F[atomFamily celdas] --> A1[atomo celda A1]
F --> A2[atomo celda A2]
F --> B1[atomo celda B1]
A1 --> C[celda calculada C1]
A2 --> C
C --> V[vista de C1]
B1 --> W[vista de B1]
style F fill:#89b4fa,color:#11111b
style C fill:#a6e3a1,color:#11111b

El ciclo de vida que nadie recoge

La memoización que hace correcta a la familia es también su punto débil: el mapa interno crece y nada lo vacía por su cuenta. Una familia parametrizada por identificadores de una lista infinita, o por coordenadas visitadas durante una sesión larga, acumula átomos que ya nadie observa y que sin embargo siguen ocupando memoria junto a sus valores en el store. La API expone operaciones explícitas para recortar ese mapa, y usarlas es responsabilidad del código, no del sistema.

const tareaAtom = atomFamily((id: string) => atom({ hecha: false }))

// eliminar una entrada concreta cuando su elemento desaparece del dominio
tareaAtom.remove('t-42')

// recortar por criterio: por ejemplo, todo lo creado antes de un instante
tareaAtom.setShouldRemove((creadoEn, _id) => Date.now() - creadoEn > 300_000)

La persistencia como nodo del grafo

atomWithStorage produce un átomo cuyo valor se lee del almacenamiento al inicializarse y se escribe en él con cada cambio. La virtud del diseño es que el resultado es un átomo normal: participa en el grafo como cualquier otro, otros derivados pueden leerlo y sus dependientes se recomputan igual. La persistencia deja de ser una capa aparte con su propia coreografía de efectos y se convierte en una propiedad del nodo.

import { atomWithStorage, createJSONStorage } from 'jotai/utils'

export const preferenciasAtom = atomWithStorage('prefs', {
  tema: 'oscuro',
  idioma: 'es',
})

// el almacen es intercambiable: sesion en lugar de local, o cualquier otro backend
export const borradorAtom = atomWithStorage(
  'borrador',
  '',
  createJSONStorage(() => sessionStorage),
)

La firma esconde una decisión importante: el valor por defecto no es un simple respaldo para la primera visita, sino el valor que el átomo tendrá siempre que la lectura del almacén falle o devuelva algo inservible. Un dato guardado por una versión anterior de la aplicación, con una forma que el código actual ya no entiende, entrará en el grafo sin que nada lo valide. Persistir es abrir una frontera de confianza con el pasado, y en aplicaciones que evolucionan conviene versionar la clave o validar lo leído antes de aceptarlo, exactamente igual que se validaría una respuesta de red.

Dos comportamientos suelen sorprender. El primero es que la sincronización entre pestañas viene incluida: el almacén por defecto se suscribe a los eventos de almacenamiento del navegador, de modo que cambiar el tema en una pestaña lo cambia en las demás sin una línea de coordinación. El segundo es que el almacén es un punto de extensión, no una imposición: sustituirlo permite persistir en almacenamiento asíncrono, en una base de datos local o en un backend remoto conservando exactamente la misma interfaz de átomo.

Persistir con criterio exige además elegir qué merece sobrevivir. Las preferencias del usuario, los borradores no enviados y el estado de navegación lo merecen; las cachés de datos remotos y los estados transitorios de la interfaz casi nunca, porque resucitar un dato caducado es peor que no tenerlo. La pregunta útil no es qué se puede persistir sino qué resultaría inquietante encontrar intacto tras una semana sin abrir la aplicación.

Combinar ambas utilidades es donde el modelo se luce. Una familia cuya fábrica devuelve átomos persistidos produce, en una línea, una colección de valores independientes que sobreviven a la recarga y se mantienen coherentes entre pestañas.

const notaAtom = atomFamily((id: string) =>
  atomWithStorage(`nota:${id}`, ''),
)

Esa línea, sin embargo, arrastra una obligación que el ejemplo no muestra: retirar el átomo de la familia no borra su entrada del almacenamiento. Eliminar una nota debe hacer ambas cosas, y olvidarlo produce un almacén que crece indefinidamente con claves de entidades que ya no existen.

Hidratación: el desajuste inevitable

El servidor no tiene acceso al almacenamiento del navegador. Esto significa que el primer renderizado en servidor usará siempre el valor inicial por defecto, mientras que el primer renderizado en cliente podría usar el valor persistido, y React detectará una divergencia entre ambos árboles. El síntoma es un aviso de hidratación desajustada y, con frecuencia, un parpadeo visible: la interfaz aparece en tema claro durante un instante antes de saltar al oscuro que el usuario había elegido.