Nanostores: el store diminuto y agnóstico

Todo lo que este track ha estudiado hasta aquí comparte un supuesto tan interiorizado que cuesta verlo: que la aplicación es un único árbol de componentes de un único framework. Redux vive en un proveedor de React, Zustand expone un hook, Jotai necesita su contexto, Valtio sirve instantáneas a un render. Cambia ese supuesto —imagina una página con tres islas interactivas escritas en tres frameworks distintos, cada una montada por separado sobre HTML estático— y todas esas herramientas se vuelven incómodas o directamente inaplicables. Nanostores es la respuesta a ese escenario: un store que no sabe nada de ningún framework, que pesa menos que la mayoría de los iconos de tu interfaz y que existe fuera del árbol porque nunca estuvo dentro. Esta lección explica por qué esa independencia deja de ser una curiosidad y se vuelve necesaria.

El problema que las islas plantean

En una aplicación de página única el estado compartido es fácil de razonar porque existe un único punto de montaje y un único árbol. En una arquitectura de islas ese punto no existe. Astro renderiza HTML en el servidor y salpica la página con componentes interactivos independientes que se hidratan por separado, cada uno con su propia raíz, sin ancestro común en tiempo de ejecución. Dos islas de React en la misma página no comparten contexto: son dos aplicaciones distintas que casualmente conviven en el mismo documento.

La consecuencia es inmediata y desagradable. Un carrito de compra cuyo contador vive en la cabecera y cuyo botón de añadir vive en la ficha de producto no puede comunicarse por contexto, porque no hay proveedor que envuelva a ambos. Poner un proveedor en cada isla crea dos estados independientes que divergen. Y montar toda la página como una única aplicación cliente derrota el propósito de haber elegido islas, que era enviar el mínimo de JavaScript posible.

Conviene notar que este no es un problema exótico de una herramienta concreta. Reaparece idéntico en micro frontends, en widgets incrustados en páginas ajenas y en cualquier migración gradual donde dos frameworks conviven durante meses. El árbol único era una condición del entorno, no una ley, y varias corrientes de la última década la han roto a la vez por motivos distintos.

La solución que el problema pide es un estado que viva fuera de todos los árboles, en el módulo, y al que cada isla se suscriba cuando le toque existir. Eso es exactamente un store agnóstico, y esa es la razón por la que la documentación de Astro recomienda nanostores en vez de las alternativas populares. No es una preferencia estética: es la única forma en que las piezas encajan.

flowchart TD
H[HTML estatico del servidor] --> I1[isla cabecera en React]
H --> I2[isla ficha en Svelte]
H --> I3[isla panel en Vue]
S[store en el modulo] --- I1
S --- I2
S --- I3
style S fill:#f9e2af,color:#11111b
style I1 fill:#89b4fa,color:#11111b
style I2 fill:#a6e3a1,color:#11111b
style I3 fill:#cba6f7,color:#11111b

Un núcleo que no sabe de vistas

El diseño de nanostores empieza por una decisión de alcance: el paquete central no importa ningún framework y no expone ningún hook. Ofrece stores con tres operaciones —leer, escribir y suscribirse— y nada más. Todo lo específico de una vista vive en paquetes separados de adaptación, tan finos que apenas son un envoltorio sobre la suscripción.

import { atom } from 'nanostores'

export const contador = atom(0)

contador.get()
contador.set(contador.get() + 1)

const cancelar = contador.subscribe((valor) => {
  console.log('nuevo valor', valor)
})

Ese fragmento no menciona React, ni Vue, ni Astro, y funciona igual en un módulo de servidor, en un trabajador web o en una prueba unitaria sin entorno de navegador. La adaptación a cada framework se importa aparte y consiste en poco más que conectar la suscripción al mecanismo de reactividad del anfitrión.

import { useStore } from '@nanostores/react'
import { contador } from './store'

function Contador() {
  const valor = useStore(contador)
  return <button onClick={() => contador.set(valor + 1)}>{valor}</button>
}

Pereza, ciclo de vida y coste proporcional

Dos rasgos del diseño merecen ser entendidos y no solo enumerados, porque cambian cómo se escribe el código. El primero es la pereza. Un store de nanostores permanece inerte mientras nadie lo escucha: no ejecuta su lógica de inicialización, no abre conexiones, no calcula derivados. En cuanto llega el primer suscriptor se monta, y cuando el último se va, tras un breve margen, se desmonta y libera lo que tuviera abierto. Ese ciclo de vida está expuesto y es utilizable.

import { atom, onMount } from 'nanostores'

export const reloj = atom(Date.now())

onMount(reloj, () => {
  const id = setInterval(() => reloj.set(Date.now()), 1000)
  return () => clearInterval(id)
})

El intervalo no existe hasta que alguna isla se suscribe al reloj, y desaparece cuando la última se desmonta. En una página con islas que se hidratan según visibilidad, ese comportamiento es exactamente lo que hace falta: los recursos siguen a los consumidores en vez de existir por si acaso. Compáralo con un store global tradicional, que se inicializa al importar el módulo y mantiene vivo lo que abrió hasta que se descarga la página.

La pereza tiene también una lectura arquitectónica que va más allá del ahorro. Un store que se monta con su primer oyente y se desmonta con el último es, en la práctica, un recurso con ciclo de vida propio, y eso permite colocar dentro del módulo de estado cosas que normalmente acaban dispersas por los efectos de los componentes: una conexión persistente, un temporizador, un observador del navegador. La ventaja no es estética. Cuando ese recurso vive en el store, su apertura y su cierre están escritos en un solo sitio y no dependen de que cada consumidor recuerde limpiar lo suyo, que es el origen habitual de las fugas.

El segundo rasgo es el coste proporcional. Como cada store es una exportación independiente y no un miembro de un objeto grande, el análisis estático del empaquetador puede eliminar los que una página concreta no toca. En una aplicación de página única eso importa poco, porque todo acaba en el mismo paquete; en un sitio con decenas de páginas y unas pocas islas por página, importa mucho, porque cada página paga solo el estado que usa.

Dónde encaja y dónde no

La honestidad exige delimitar. Nanostores gana con claridad en tres escenarios. El primero es el que motivó su diseño: sitios con islas, sea Astro, Eleventy con hidratación parcial o cualquier montaje múltiple. El segundo es el de aplicaciones que conviven con varios frameworks a la vez, un caso frecuente en migraciones graduales y en micro frontends, donde tener el estado en terreno neutral evita duplicarlo. El tercero es el de bibliotecas y componentes distribuibles que necesitan estado propio y no pueden imponer un framework a quien las consume.

Hay un cuarto escenario menos obvio y cada vez más frecuente: el código que debe correr igual en el servidor y en el cliente. Como el núcleo no depende de ningún framework ni de ninguna API del navegador, un módulo de stores se importa sin ceremonia desde una función de servidor, desde una tarea de compilación o desde una prueba en Node. Eso convierte al store en un lugar razonable para alojar lógica de dominio compartida entre ambos lados, algo que un store atado al ciclo de vida de React nunca pudo ser sin envoltorios.

// mismo modulo importable desde una isla, desde el servidor o desde una prueba
import { atom, computed } from 'nanostores'

export const lineas = atom<Array<{ precio: number; cantidad: number }>>([])
export const unidades = computed(lineas, (items) =>
  items.reduce((suma, l) => suma + l.cantidad, 0),
)

Fuera de esos escenarios el cálculo cambia. En una aplicación de React de página única, Zustand ofrece una ergonomía mejor y un ecosistema más grande a cambio de dos kilobytes más, y elegir nanostores por el tamaño sería optimizar la métrica equivocada. Para grafos de derivación densos, Jotai modela mejor. Para escritura imperativa y anidada, Valtio es más natural. La independencia de framework es una virtud cara de aprovechar si nadie va a usarla.