Async y Suspense: la promesa como nodo del grafo

En Redux, un dato remoto exigía maquinaria: un middleware que interceptase acciones, una máquina de estados de petición escrita a mano con sus banderas de carga y error, y una disciplina para que ninguna vista leyera datos a medio llegar. Jotai hace una jugada distinta y más económica: no añade nada. Un átomo cuya función de lectura devuelve una promesa es un átomo normal cuyo valor resulta ser una promesa, y el resto lo pone React, que sabe suspender un componente hasta que una promesa leída durante el renderizado resuelva. La consecuencia es una reducción conceptual notable: un solo mecanismo cubre estado síncrono, derivado y asíncrono, y las tres formas se componen entre sí sin adaptadores. Lo que esa uniformidad no elimina son las decisiones de experiencia, que se trasladan intactas al lugar donde se colocan los límites de suspensión.

La promesa como valor cualquiera

Un átomo asíncrono se declara igual que uno derivado, con la única diferencia de que su función de lectura es asíncrona. Lo relevante no es la sintaxis sino la integración: ese átomo puede leer otros átomos, otros átomos pueden leerlo a él, y la cadena de dependencias funciona sin distinción entre nodos síncronos y asíncronos.

import { atom } from 'jotai'

const usuarioIdAtom = atom('u-1')

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

// un derivado sincrono puede leer un atomo async: get devuelve el valor ya resuelto
const nombreAtom = atom((get) => get(usuarioAtom).nombre)

Ese último detalle es el que hace que el modelo sea más que azúcar sintáctico. Dentro de un derivado, leer un átomo asíncrono devuelve el valor resuelto, no la promesa, porque el sistema espera por él antes de evaluar el cuerpo. La composición de datos remotos con datos locales deja de requerir la coreografía habitual de comprobar si el dato ya llegó antes de usarlo: la ausencia de dato se expresa como suspensión, no como una rama condicional repetida en cada consumidor.

Conviene precisar el mecanismo, porque la palabra espera induce a error. El átomo no bloquea nada: devuelve la promesa, y es React quien, al encontrarla durante el renderizado, interrumpe ese componente y lo reintenta cuando resuelve. El grafo, mientras tanto, sigue siendo síncrono en su propagación; lo asíncrono es el valor que transporta uno de sus nodos. Esta distinción explica por qué la asincronía no exigió inventar un tipo nuevo de átomo ni un canal paralelo de notificación: bastó con que el sistema supiera desenvolver una promesa al leerla desde otro derivado.

La reevaluación funciona igual que en el caso síncrono. Si usuarioIdAtom cambia, el átomo asíncrono se recomputa, lo que significa lanzar una petición nueva, y todos sus dependientes se recomputan en cascada cuando esa petición resuelve. La invalidación manual —el problema que las librerías de datos resuelven con claves y etiquetas— aquí es simplemente una arista del grafo.

flowchart TD
ID[usuarioIdAtom] --> U[usuarioAtom async]
U --> N[nombreAtom]
U --> P[permisosAtom]
N --> V[cabecera]
P --> W[menu lateral]
style U fill:#f9e2af,color:#11111b
style V fill:#a6e3a1,color:#11111b

Dónde poner el límite de suspensión

Un componente que lee un átomo asíncrono no resuelto suspende, y el Suspense ancestro más cercano muestra su contenido de reserva. Esto convierte la colocación de esos límites en la decisión de diseño central de toda la lección, porque determina qué porción de la interfaz desaparece mientras se espera. Un único límite en la raíz produce el peor resultado posible: la aplicación entera se sustituye por un cargador cada vez que cualquier dato se pide.

import { Suspense } from 'react'

function Panel() {
  return (
    <>
      <Suspense fallback={<CabeceraEsqueleto />}>
        <Cabecera />
      </Suspense>
      <Suspense fallback={<ListaEsqueleto />}>
        <Lista />
      </Suspense>
    </>
  )
}

Con límites independientes, la cabecera y la lista se resuelven por separado y cada región muestra su propio esqueleto. Existe además una trampa recurrente: si un componente lee un átomo asíncrono y solo entonces renderiza a un hijo que lee otro, las dos peticiones se encadenan en serie aunque fuesen independientes. Esa cascada no la causa Jotai sino la estructura del árbol, y se resuelve leyendo ambos átomos al mismo nivel o combinándolos en un derivado que los pida en paralelo.

Recarga sin parpadeo y suspensión como dato

El modelo tiene un comportamiento incómodo por defecto: cuando una dependencia cambia y el átomo asíncrono se relanza, el consumidor vuelve a suspender y el contenido ya visible desaparece. Cambiar de usuario hace que la ficha entera parpadee en lugar de actualizarse. La solución idiomática es conservar el valor anterior mientras el nuevo se resuelve, de modo que la transición sea una actualización y no una reaparición.

import { atom } from 'jotai'
import { loadable, unwrap } from 'jotai/utils'

// conserva el valor previo durante la recarga: sin parpadeo entre usuarios
const usuarioEstableAtom = unwrap(usuarioAtom, (previo) => previo)

// convierte la suspension en datos: estado explicito en lugar de excepcion
const usuarioCargableAtom = loadable(usuarioAtom)

Las dos utilidades resuelven necesidades distintas y conviene no confundirlas. La primera mantiene visible el dato anterior y evita el parpadeo sin renunciar al modelo declarativo. La segunda renuncia deliberadamente a la suspensión y devuelve un objeto con un estado explícito de carga, error o éxito, lo que resulta útil cuando se necesita mostrar un indicador en línea junto al contenido antiguo, o cuando el componente que lee está fuera de cualquier límite de suspensión y no debe derribar el árbol.

La escritura asíncrona es otra cosa

Es frecuente asumir que si la lectura asíncrona se resuelve sola, la escritura también. No es así, y la distinción importa. Una operación que envía datos al servidor no es una derivación sino una intención con efectos, y su lugar natural es el átomo de acción, cuya función escritora puede ser asíncrona y coordinar tanto la petición como la actualización de los átomos afectados.

const guardandoAtom = atom(false)

const guardarUsuarioAtom = atom(null, async (get, set, datos: Datos) => {
  set(guardandoAtom, true)
  try {
    const res = await fetch('/api/usuarios', { method: 'POST', body: JSON.stringify(datos) })
    set(usuarioIdAtom, (await res.json()).id)   // dispara la recarga del grafo
  } finally {
    set(guardandoAtom, false)
  }
})

Queda una arista incómoda que conviene nombrar sin adornos: la cancelación. Si una dependencia cambia dos veces en rápida sucesión, se lanzan dos peticiones y nada garantiza que resuelvan en orden. El sistema descarta el resultado de la evaluación obsoleta, pero la petición en vuelo sigue consumiendo red y no se aborta sola. Cuando esto importa —búsquedas mientras se teclea, filtros agresivos— hay que llevar la cancelación a mano con una señal de aborto, y ese es precisamente el tipo de trabajo que una librería de datos dedicada ya tiene resuelto.