Jotai: estado atómico de abajo arriba

Zustand hizo el store más ligero, pero seguía siendo un store: un objeto grande y central del que los componentes extraen porciones de arriba abajo. Jotai, también de Poimandres y obra de Daishi Kato, invierte la dirección. En vez de partir de un todo y seleccionar partes, partes de piezas mínimas —los átomos— y las compones hacia arriba. El estado deja de ser un árbol que talas y pasa a ser un grafo que cultivas: átomos primitivos en la base, átomos derivados que dependen de ellos, y una máquina de recálculo que mantiene el grafo consistente sin que muevas un dedo. En unos 4KB, es la respuesta idiomática cuando el estado es interdependiente y derivado.

El átomo primitivo y el grafo derivado

Un átomo es una unidad mínima de estado. El primitivo se declara con un valor inicial; el derivado se declara con una función que lee otros átomos mediante get y devuelve un valor computado. Esa función define una arista en el grafo de dependencias:

import { atom } from 'jotai'

export const contadorAtom = atom(0)                              // primitivo
export const dobleAtom = atom((get) => get(contadorAtom) * 2)    // derivado de solo lectura
export const parAtom = atom((get) => get(contadorAtom) % 2 === 0)

La propiedad crucial: dobleAtom y parAtom no se recalculan nunca por su cuenta. Jotai sabe que dependen de contadorAtom porque lo leyeron con get, así que solo los recomputa cuando contadorAtom cambia, y solo notifica a los componentes que consumen precisamente esos derivados. La memoización de valores derivados —que en React harías a mano con useMemo y sus arrays de dependencias, siempre a riesgo de olvidar una— aquí es la mecánica por defecto del sistema, y las dependencias se descubren solas en cada ejecución en vez de declararse.

flowchart TD
P[contadorAtom primitivo] --> D[dobleAtom derivado]
P --> E[parAtom derivado]
D --> V[vista A]
E --> W[vista B]
P --> X[vista C]
style P fill:#89b4fa,color:#11111b
style D fill:#a6e3a1,color:#11111b
style E fill:#a6e3a1,color:#11111b

Consumir átomos en componentes

La API imita deliberadamente a useState, y esa familiaridad es parte de su diseño: reducir la fricción de adopción. useAtom devuelve la pareja valor y actualizador; cuando solo lees, useAtomValue evita suscribir la escritura; cuando solo escribes, useSetAtom evita re-renderizar por lecturas que no te importan:

import { useAtom, useAtomValue, useSetAtom } from 'jotai'

function Contador() {
  const [contador, setContador] = useAtom(contadorAtom)
  const doble = useAtomValue(dobleAtom)
  return <button onClick={() => setContador((c) => c + 1)}>{contador} / {doble}</button>
}

Los átomos derivados pueden ser también de escritura, definiendo una segunda función que recibe get y set y traduce una intención en mutaciones de los átomos base. Este patrón —el átomo de acción— encapsula transiciones complejas detrás de una interfaz simple, y es el equivalente atómico de una acción de Zustand:

export const incrementarAtom = atom(
  null,                                              // sin valor de lectura: es una accion
  (get, set) => set(contadorAtom, get(contadorAtom) + 1),
)

La migración desde useState es casi mecánica, y eso no es casual sino un objetivo de diseño: un estado local que de pronto necesita compartirse entre componentes lejanos se promueve de useState a un átomo cambiando una línea y sin levantar el estado por toda la jerarquía. Desaparece el prop drilling y desaparece también el clásico levantamiento de estado al ancestro común, que acoplaba componentes solo para compartir un dato entre dos hojas distantes del árbol.

Ese camino de crecimiento —de local a global sin reescritura— es una de las razones prácticas de la adopción de Jotai en bases que empiezan pequeñas y crecen. No pagas por adelantado una infraestructura global; conviertes en global solo lo que la evidencia demuestra que debe serlo, y la conversión es barata justo en el momento en que hace falta.

De abajo arriba: cuándo los átomos ganan

La diferencia con Zustand no es de peso sino de dirección del diseño. Un store es de arriba abajo: decides la forma del todo y extraes partes. Los átomos son de abajo arriba: defines fragmentos independientes y dejas que las dependencias entre ellos dibujen la estructura. Esa inversión tiene una consecuencia práctica profunda. En un store, el acoplamiento es implícito —todo vive en el mismo objeto y depende de que tú lo mantengas ordenado—; con átomos, el acoplamiento es explícito y local —un derivado declara exactamente de qué depende y de nada más—, de modo que el grafo entero es legible pieza a pieza sin cargar el todo en la cabeza.

Esto brilla exactamente donde Zustand incomoda: cuando el estado es una red de valores que dependen unos de otros y cuya recomputación selectiva importa. El caso canónico es el estado derivado en cascada —un filtro que afecta a una lista, que afecta a un total, que afecta a un resumen— donde cada eslabón debe recalcularse si y solo si su fuente cambió. Modelado como átomos, el grafo se ocupa de la propagación mínima; modelado como un store plano, tú vigilas a mano qué depende de qué y cuándo invalidar. Cuanto más denso el tejido de dependencias, mayor la ventaja de los átomos.

Hay un coste honesto en este poder: la dispersión. Un estado modelado como cincuenta átomos sueltos puede costar más de abarcar de un vistazo que un único store donde todo está a la vista, y sin disciplina de nomenclatura y colocación el grafo degenera en un laberinto de dependencias implícitas. Jotai premia a quien piensa en grafos y castiga a quien solo trocea; la atomicidad no es gratis, es una inversión que rinde cuando el problema de verdad tiene forma de red y se desperdicia cuando no.

Ese descubrimiento dinámico de dependencias, además, es más potente de lo que parece. Si un derivado lee un átomo dentro de una rama condicional, la dependencia solo existe cuando esa rama se ejecuta, y el grafo se reconfigura solo según el camino tomado. No hay array de dependencias que mantener sincronizado con el cuerpo de la función, esa fuente perenne de bugs en useMemo y useEffect: el grafo es siempre exacto porque se reconstruye de la ejecución real, no de una lista que prometiste mantener al día.

Un ejemplo concreto vale más que la lista. Un átomo persistido y una porción derivada con comparación propia se declaran así, y participan en el grafo como cualquier otro átomo:

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

export const preferenciasAtom = atomWithStorage('prefs', { tema: 'oscuro', idioma: 'es' })
export const temaAtom = selectAtom(preferenciasAtom, (p) => p.tema)

temaAtom solo notifica a sus consumidores cuando tema cambia, aunque idioma cambie mil veces: la granularidad del grafo llega hasta el campo. atomWithStorage, además, sincroniza con almacenamiento y entre pestañas sin que escribas una línea de coordinación.

Átomos asíncronos y el grafo que respira

El golpe de gracia del modelo es que la asincronía es solo otro nodo del grafo. Un átomo cuya función de lectura es async devuelve una promesa, y Jotai la integra con Suspense de React: el componente que lo consume suspende hasta que resuelve, sin banderas de loading a mano.

export const usuarioAtom = atom(async (get) => {
  const id = get(usuarioIdAtom)
  const res = await fetch(`/api/usuarios/${id}`)
  return res.json()                    // el componente suspende hasta resolver
})

Lo potente es que este átomo async participa en el grafo como cualquier otro: si usuarioIdAtom cambia, la petición se relanza sola y los derivados que dependían del usuario se recomputan en cascada. Combinado con atomFamily, obtienes una caché parametrizada por identidad sin escribir una línea de gestión de caché:

import { atomFamily } from 'jotai/utils'

export const tareaAtom = atomFamily((id: string) =>
  atom(async (get) => {
    const res = await fetch(`/api/tareas/${id}`)
    return res.json()
  }),
)

Dicho esto, para estado de servidor serio —con revalidación, reintentos y sincronización— sigue siendo mejor una herramienta dedicada como TanStack Query; los átomos async brillan cuando ese estado remoto debe entretejerse con estado de cliente derivado en el mismo grafo.

Merece subrayarse la elegancia de que la asincronía no sea un caso especial. En Redux, un dato asíncrono exigía middleware —thunks o sagas— y una máquina de estados de petición escrita a mano. En Jotai, una promesa es un valor como cualquier otro dentro del grafo, y Suspense se encarga del estado de carga. La reducción conceptual es enorme: un solo mecanismo, el átomo, cubre estado síncrono, derivado y asíncrono, y las tres formas se componen entre sí sin costuras ni adaptadores.

Esa uniformidad tiene además un efecto pedagógico que no conviene pasar por alto. Una vez entiendes el átomo, entiendes todo Jotai: no hay una API para lo local, otra para lo derivado y otra para lo async, como ocurría en la maraña de conceptos de Redux. La curva de aprendizaje es corta porque la superficie conceptual es minúscula, y esa economía de ideas es, en sí misma, una forma de potencia: menos que aprender, menos que olvidar, menos donde equivocarse.