Átomos derivados: el grafo que se construye solo

Si el átomo primitivo fuese todo lo que ofrece Jotai, sería un useState global con más ceremonia. La potencia está en el segundo tipo de átomo: el derivado, que no almacena nada y se define exclusivamente por una función que lee otros átomos. Ese acto de lectura tiene una consecuencia que conviene subrayar antes de nada: al leer, el átomo declara una dependencia. No hay lista que mantener, ni array que sincronizar con el cuerpo de la función, ni riesgo de olvidar una entrada. El grafo se construye solo, a partir de lo que la ejecución real leyó, y se reconstruye en cada evaluación. De ahí nace tanto la ergonomía del modelo como su garantía de consistencia.

El derivado de solo lectura y la dependencia implícita

Un derivado de solo lectura se declara pasando a atom una función que recibe un lector y devuelve un valor. Cada átomo que esa función lee queda registrado como dependencia, y el resultado se cachea hasta que alguna de esas dependencias cambie. La derivación encadena sin límite: un derivado puede leer a otros derivados, y el sistema resuelve la cadena entera.

import { atom } from 'jotai'

const precioAtom = atom(100)
const cantidadAtom = atom(2)
const descuentoAtom = atom(0)

const subtotalAtom = atom((get) => get(precioAtom) * get(cantidadAtom))
const baseAtom = atom((get) => get(subtotalAtom) * (1 - get(descuentoAtom)))
const ivaAtom = atom((get) => get(baseAtom) * 0.21)
const totalAtom = atom((get) => get(baseAtom) + get(ivaAtom))

Un derivado no se evalúa hasta que alguien lo observa, y esa pereza tiene consecuencias que conviene anticipar. Declarar cien derivados no cuesta nada mientras nadie los lea; el trabajo aparece con la primera suscripción y desaparece cuando el último consumidor se va. Por eso un cuerpo de derivación debe ser una función pura: si contiene efectos, su ejecución quedará atada a un calendario que depende de quién mira y cuándo, es decir, a algo que el código no controla.

La comparación con la memoización manual de React es instructiva y no favorece a esta última. Un useMemo exige declarar sus dependencias en un array separado del cuerpo de la función, y esa duplicación es una promesa que el programador hace y que nada verifica en tiempo de ejecución: si el cuerpo cambia y el array no, el valor memoizado se queda obsoleto sin que nadie avise. El derivado no puede desincronizarse porque no hay dos sitios que sincronizar; la dependencia es un efecto del acto de leer, no una declaración paralela.

Merece la pena detenerse en lo que ocurre bajo la superficie durante esa evaluación. El lector que recibe la función no es un simple acceso al valor: es un instrumento de registro que, además de devolver el dato, anota la arista en el grafo y suscribe al derivado a futuros cambios de esa fuente. Como el registro se rehace en cada evaluación, las aristas que dejaron de recorrerse se descartan y las nuevas se añaden, de modo que el grafo nunca conserva dependencias fósiles de una ejecución anterior. Esa reconstrucción continua es lo que permite afirmar que el grafo describe el programa real y no una intención declarada.

Esa propiedad se vuelve más notable con dependencias condicionales. Si un derivado lee un átomo solo dentro de una rama, la dependencia existe únicamente cuando esa rama se ejecuta, y el grafo se reconfigura en cada evaluación según el camino tomado. Un componente que solo depende del modo simple no se recomputa cuando cambian los átomos que únicamente el modo avanzado consulta.

const modoAvanzadoAtom = atom(false)
const recargoAtom = atom(12)

// la dependencia sobre recargoAtom solo existe cuando el modo avanzado esta activo
const totalFinalAtom = atom((get) =>
  get(modoAvanzadoAtom) ? get(totalAtom) + get(recargoAtom) : get(totalAtom),
)

Escribir a través del grafo

La segunda función que acepta atom convierte a un derivado en escribible. Recibe un lector, un escritor y el valor entrante, y su cuerpo traduce esa intención en escrituras sobre átomos primitivos. Cuando el primer argumento es nulo, el átomo no tiene valor de lectura y funciona como pura acción: el equivalente atómico de un action creator que despacha varias mutaciones coordinadas.

const carritoAtom = atom<string[]>([])
const cuponAtom = atom<string | null>(null)

// atomo de accion: sin valor de lectura, solo coordina escrituras
const vaciarCarritoAtom = atom(null, (_get, set) => {
  set(carritoAtom, [])
  set(cuponAtom, null)
})

// derivado de lectura y escritura: dos representaciones de una sola fuente
const celsiusAtom = atom(20)
const fahrenheitAtom = atom(
  (get) => get(celsiusAtom) * 9 / 5 + 32,
  (_get, set, nuevoF: number) => set(celsiusAtom, (nuevoF - 32) * 5 / 9),
)

Nótese que el escritor no está obligado a escribir el mismo átomo que el lector consulta, ni siquiera a escribir uno solo. Esa libertad convierte al derivado escribible en un punto de traducción entre el vocabulario de la interfaz y el del dominio: la vista habla de grados Fahrenheit, de porcentajes o de etiquetas, y el modelo sigue hablando de la única representación canónica que decidió guardar.

El átomo de temperatura merece atención porque ilustra una técnica que trasciende el ejemplo. Existen dos representaciones visibles del mismo hecho físico, pero solo una es estado: la otra es derivación bidireccional. Ambas vistas quedan siempre coherentes porque no hay dos datos que sincronizar. Ese patrón —una fuente de verdad y varias proyecciones escribibles sobre ella— resuelve limpiamente problemas que en un store plano degeneran en efectos que copian un campo en otro y en carreras entre esas copias.

El átomo de acción, por su parte, restituye algo que el modelo atómico parecía haber perdido frente a Redux: un lugar con nombre donde vive una transición completa. Vaciar el carrito no es escribir en dos átomos desde el componente, sino invocar una operación que encapsula esa coordinación y puede probarse en aislamiento, sin montar un solo componente de React.

Hay además una razón de consistencia que suele descubrirse tarde. Cuando un componente escribe dos átomos por su cuenta, entre ambas escrituras existe un instante en que el estado global es incoherente: el carrito ya está vacío pero el cupón sigue aplicado. Cualquier suscriptor que reaccione en ese hueco observa una combinación que el dominio considera imposible. Al mover ambas escrituras al cuerpo de un átomo de acción, la coordinación queda expresada en un solo lugar y se vuelve revisable como una unidad, que es la condición previa para razonar sobre atomicidad en el sentido transaccional del término, no en el de la partícula.

Queda un límite que conviene tener presente para no forzar la herramienta. Un derivado escribible sigue siendo un nodo del grafo, no un lugar donde alojar reglas de negocio extensas ni orquestaciones largas. Cuando la traducción entre la vista y el dominio empieza a requerir validaciones, ramas y llamadas externas, la señal es que esa lógica pertenece a una función de dominio ordinaria que el átomo se limita a invocar. El grafo gana claridad cuando sus nodos son pequeños y su significado cabe en una frase.

Orden topológico y ausencia de glitches

Cuando una escritura ocurre, el sistema no reevalúa el grafo entero: recorre las aristas salientes del átomo escrito y recomputa únicamente la subred alcanzable. Ese recorrido se hace en orden topológico, lo que garantiza dos propiedades no negociables. La primera es que ningún derivado se recomputa más de una vez por transacción aunque varias de sus dependencias hayan cambiado a la vez. La segunda, más sutil, es que ningún derivado se evalúa con una mezcla de valores nuevos y viejos.

flowchart TD
P[precio] --> S[subtotal]
C[cantidad] --> S
S --> B[base]
DC[descuento] --> B
B --> IVA[iva]
B --> T[total]
IVA --> T
style B fill:#89b4fa,color:#11111b
style T fill:#cba6f7,color:#11111b

La poda del recorrido es tan importante como su orden. Un cambio en el descuento no toca el subtotal, porque el subtotal no lo lee, y por tanto ninguna vista suscrita únicamente al subtotal vuelve a renderizarse. Ese recorte no depende de que nadie haya escrito un comparador ni memoizado un selector: se deduce de la topología, que a su vez se dedujo de las lecturas. Cuando el grafo crece hasta cientos de nodos, esta propiedad es la diferencia entre un sistema cuyo coste por escritura es proporcional al tamaño del subgrafo afectado y otro cuyo coste es proporcional al número total de suscriptores.

El diamante del diagrama es el caso de prueba clásico. El total depende de la base y del iva, y el iva depende también de la base. Si un sistema propagase sin orden, un cambio en la base podría alcanzar al total antes que al iva, produciendo por un instante un total calculado con la base nueva y el iva viejo. Ese estado intermedio incoherente es lo que la literatura de programación reactiva llama glitch, y su peligro no es visual sino semántico: un efecto que se dispare en ese instante observa un mundo que jamás debió existir. La propagación topológica lo hace imposible porque un nodo espera a que todos sus padres estén resueltos antes de calcularse.