Provider y scopes: aislar árboles de átomos

La primera lección insistió en que un átomo no guarda su valor. Es aquí donde esa afirmación deja de ser una curiosidad conceptual y se convierte en la característica más práctica del modelo. Si la definición vive en el módulo y el valor vive en un store, entonces basta con cambiar de store para que el mismo grafo de átomos tenga otro conjunto de valores, sin tocar una línea de sus declaraciones. Eso permite instanciar el mismo formulario tres veces en la misma página sin que compartan estado, aislar cada petición en el servidor para que ningún usuario vea datos de otro, y montar un test con estado sembrado y garantizado limpio. El mecanismo que hace todo esto es un componente sencillo, Provider, y una función que fabrica stores. La sutileza no está en la API sino en saber cuándo el ámbito global implícito deja de ser suficiente.

El store implícito y cuándo deja de bastar

Sin ningún Provider, los átomos operan contra un store por defecto que existe a nivel de módulo y es único para todo el proceso. Para una aplicación de cliente con un solo árbol y un solo usuario, esa comodidad es correcta y no hay razón para complicarla. El problema aparece en tres situaciones concretas: cuando el mismo grafo debe existir varias veces a la vez, cuando el proceso atiende a varios usuarios simultáneamente, y cuando varias pruebas comparten el mismo proceso.

import { Provider, createStore } from 'jotai'

// un store explicito es un objeto con get, set y sub: se puede usar fuera de React
const store = createStore()
store.set(temaAtom, 'claro')
console.log(store.get(temaAtom))

function App() {
  return (
    <Provider store={store}>
      <Contenido />
    </Provider>
  )
}

El store explícito tiene un valor añadido que suele pasar desapercibido: es utilizable fuera de React. Leer y escribir átomos desde un manejador de eventos del navegador, desde un enrutador o desde una capa de integración no obliga a montar componentes, lo que resulta esencial para conectar el grafo con código imperativo que no vive en el árbol.

Un grafo, muchas instancias

El caso que mejor ilustra el ámbito es un componente complejo que debe aparecer varias veces en la misma pantalla. Un panel de filtros, un editor incrustado, una ficha comparativa: cada instancia necesita su propio estado, pero la lógica —los átomos y sus derivaciones— debe escribirse una sola vez. En un store central esto obliga a parametrizar todo el estado por un identificador de instancia y a arrastrar ese identificador por cada selector y cada acción. Con ámbitos, las declaraciones no cambian en absoluto.

flowchart TD
D[definiciones de atomos] --> S1[store instancia A]
D --> S2[store instancia B]
S1 --> V1[panel izquierdo]
S2 --> V2[panel derecho]
D --> SG[store global implicito]
SG --> VG[cabecera compartida]
style D fill:#89b4fa,color:#11111b
style SG fill:#f9e2af,color:#11111b

function Comparador() {
  return (
    <div>
      <Provider>
        <PanelDeFiltros />
      </Provider>
      <Provider>
        <PanelDeFiltros />
      </Provider>
    </div>
  )
}

Conviene entender la regla de resolución que hace esto posible, porque es la fuente de los errores más desconcertantes. Cuando un componente consume un átomo, el valor se busca en el Provider ancestro más cercano; si no hay ninguno, se usa el store implícito. Esto significa que un componente que quedó fuera del Provider por accidente seguirá funcionando, pero contra el store global, y el síntoma será un estado que no se comparte con sus hermanos sin ningún error visible. El aislamiento es silencioso en ambas direcciones.

Un store por petición

La regla en renderizado de servidor es breve y no admite excepciones: cada petición crea su propio store y lo entrega a un Provider que envuelve el árbol que se va a renderizar. Con eso, dos peticiones concurrentes ejercitan el mismo grafo de definiciones sobre dos conjuntos de valores completamente separados, y no existe ningún camino por el que una pueda observar a la otra.

import { Provider, createStore } from 'jotai'

export function renderizarPeticion(datosDeSesion: Sesion) {
  const store = createStore()
  store.set(sesionAtom, datosDeSesion)   // siembra explicita, aislada por peticion
  return (
    <Provider store={store}>
      <App />
    </Provider>
  )
}

La siembra de valores iniciales merece un tratamiento propio dentro de componentes, porque hacerla en un efecto llega tarde: el primer renderizado ya habría ocurrido con el valor por defecto, produciendo el desajuste de hidratación que la lección anterior describía. La utilidad de hidratación resuelve esto escribiendo los valores antes del primer renderizado del subárbol.

import { useHydrateAtoms } from 'jotai/utils'

function Sembrado({ usuario, children }: Props) {
  useHydrateAtoms([[usuarioAtom, usuario]])   // ocurre antes del primer render
  return <>{children}</>
}

Tests: el aislamiento por construcción

El mismo mecanismo convierte las pruebas en un problema resuelto. La dificultad clásica de probar estado global es la contaminación entre casos: una prueba deja un valor escrito y la siguiente lo hereda, produciendo fallos que dependen del orden de ejecución y desaparecen al ejecutar el caso aislado. La respuesta habitual es una función de reinicio global que hay que recordar invocar y mantener al día conforme el estado crece. Con ámbitos, esa función no hace falta: cada prueba crea su store, y la separación es estructural en vez de convenida.

import { createStore, Provider } from 'jotai'

test('el total refleja el descuento aplicado', () => {
  const store = createStore()
  store.set(precioAtom, 100)
  store.set(descuentoAtom, 0.1)

  expect(store.get(totalAtom)).toBeCloseTo(108.9)   // sin montar nada de React
})

La segunda mitad de esa prueba es la más significativa: el grafo se puede ejercitar sin React en absoluto. Un store explícito permite escribir entradas, leer derivados y suscribirse a cambios como si fuera una librería de estado independiente, lo que hace que la lógica de dominio expresada en derivaciones se pruebe con la velocidad y la simplicidad de una prueba unitaria pura, dejando el renderizado para las pruebas que de verdad lo necesitan.