Nanostores y el multi-framework: un store entre islas

Todos los gestores de estado que hemos estudiado comparten un supuesto tan básico que nunca lo enunciamos: que la aplicación es un único árbol de componentes de un único framework, con una raíz donde colocar un proveedor. La arquitectura de islas rompe ese supuesto de raíz. En una página de Astro puede haber una isla escrita en React junto a otra en Vue y otra en Svelte, cada una hidratada por separado, sin árbol común, sin contexto compartido y sin ningún lugar donde envolver a todas. Y sin embargo el carrito que muestra la cabecera tiene que enterarse cuando el botón de la ficha de producto añade un artículo. Nanostores es la respuesta más limpia a ese problema, y su respuesta consiste, una vez más, en volver al núcleo agnóstico de la lección uno.

El problema que las islas crean

Una isla es un fragmento interactivo que se hidrata solo, rodeado de HTML estático. Astro las declara con directivas como client:load o client:visible, y cada una arranca su propio runtime de forma aislada: dos islas de React en la misma página no comparten árbol ni raíz de render, y por tanto no comparten contexto. Un Provider de react-redux colocado dentro de una isla es invisible para la de al lado, aunque ambas estén escritas en React. Si además una está en React y otra en Vue, ni siquiera comparten sistema de reactividad.

Las alternativas que uno intenta antes de aceptar el diagnóstico fallan todas por la misma razón. Pasar datos por props solo funciona hacia abajo dentro de una isla y no cruza de una a otra. Los eventos personalizados sobre el objeto window funcionan, pero no tienen estado: quien llega tarde a la fiesta no puede preguntar cuál es el valor actual, y acabas reinventando un store peor. Guardar en el almacenamiento local sincroniza pestañas pero no notifica dentro de la misma página con la inmediatez que la vista necesita. Todas fracasan por carecer de alguna de las garantías del patrón, y su fracaso es una demostración indirecta de que las cuatro garantías son necesarias, no decorativas.

Esa lista deja el diagnóstico servido. Lo único que todas las islas de una página comparten es el grafo de módulos: si dos de ellas importan el mismo archivo, obtienen la misma instancia, porque el navegador evalúa cada módulo una sola vez. El contenedor de la verdad, cuando no hay árbol, es el propio sistema de módulos. Es exactamente el mecanismo que usamos en la lección uno para el contador de vanilla, y aquí deja de ser una curiosidad didáctica para volverse la única opción viable.

Nanostores: el núcleo mínimo y sus adaptadores

Conviene aclarar que nada de esto es exclusivo de Nanostores. Un store de Redux importado desde un módulo compartido resolvería el problema igual de bien en cuanto le escribieras un adaptador para cada framework, y ese ejercicio aparece al final del reto porque hacerlo una vez enseña más que cualquier explicación. La razón para preferir la librería específica es de tamaño y de mantenimiento: los adaptadores ya existen, están probados contra las particularidades de cada runtime y pesan casi nada. La arquitectura sería la misma con cualquiera de las dos.

Nanostores lleva la idea de la lección uno a su conclusión extrema: un store es un valor observable de unos cientos de bytes, sin dependencias, sin framework, y los enlaces se distribuyen como paquetes separados —uno para React, uno para Vue, uno para Svelte— que cada isla importa según lo que sea. La librería reconoce explícitamente la separación entre patrón y capa de enlace que este nivel viene demostrando.

// stores/carrito.ts — un solo modulo, importado por islas de frameworks distintos
import { atom, computed } from 'nanostores'

export const articulos = atom<Articulo[]>([])

// estado derivado: el equivalente de createSelector, memoizado y automatico
export const total = computed(articulos, (lista) =>
  lista.reduce((suma, a) => suma + a.precio * a.cantidad, 0),
)

// la frontera de escritura: funciones exportadas, no set suelto por ahi
export function anadir(articulo: Articulo) {
  articulos.set([...articulos.get(), articulo])
}

La familia de primitivas es deliberadamente corta y cada una responde a una necesidad que ya conoces del track: atom para un valor suelto, map para un objeto cuyas claves se observan por separado y así evitar repintados innecesarios, computed para el estado derivado del Nivel 5, y variantes persistentes que sincronizan el valor con el almacenamiento del navegador y entre pestañas. No hay middleware, no hay historial de acciones y no hay viaje en el tiempo: la librería elige explícitamente pagar en trazabilidad lo que gana en tamaño, y lo hace porque el contexto donde vive —islas con presupuesto ajustado de JavaScript— hace que esa sea la elección sensata.

Reconoce las piezas: get es getState, set es la escritura controlada, subscribe sigue existiendo por debajo y computed es el selector memoizado. Lo único que falta respecto a Redux es el objeto de acción con tipo, y su ausencia se paga en trazabilidad igual que en Pinia. Lo que se gana a cambio es un tamaño que cabe en el presupuesto de una isla y una independencia total del framework que la hospeda.

flowchart TD
M[modulo stores carrito ts] --> A[atom articulos y computed total]
A --> R[isla en react con useStore]
A --> V[isla en vue con useStore]
A --> S[isla en svelte con dolar store]
R -->|anadir| A
V -->|anadir| A
H[html estatico de astro] --- R
H --- V
H --- S
style M fill:#f9e2af,color:#11111b
style A fill:#f38ba8,color:#11111b
style H fill:#a6e3a1,color:#11111b

Tres islas, tres frameworks, un estado

El caso completo se ve mejor en la página que las compone. Astro no sabe nada del store ni le importa: se limita a montar tres islas independientes que resultan importar el mismo módulo.

Ese desinterés del framework anfitrión es exactamente la propiedad que buscamos. Astro no ofrece —ni necesita ofrecer— una solución de estado propia, porque el problema no es suyo: él compone HTML y decide cuándo hidratar cada fragmento. La coordinación entre fragmentos ocurre una capa por debajo, en el grafo de módulos que el navegador ya gestiona, y por eso funciona igual con cualquier combinación de tecnologías presente o futura.

// una isla de React lee y escribe el mismo atomo
import { useStore } from '@nanostores/react'
import { articulos, total, anadir } from '../stores/carrito'

export function Cabecera() {
  const suma = useStore(total)
  const lista = useStore(articulos)
  return <span>{lista.length} articulos por {suma} euros</span>
}

// una isla de Vue, en otro archivo y con otro runtime, ve exactamente lo mismo
import { useStore } from '@nanostores/vue'
import { articulos, anadir } from '../stores/carrito'

export default {
  setup() {
    const lista = useStore(articulos)
    return { lista, anadir }
  },
}

Un detalle de disciplina que el ejemplo esconde y conviene explicitar: el módulo exporta el átomo y la función anadir, pero lo correcto es que las islas escriban solo a través de la función. Exportar el átomo para leerlo es necesario; permitir que cualquier isla llame a su set desde donde le convenga disuelve la frontera de escritura y devuelve el sistema al estado del que Flux nos sacó. La regla es la misma de siempre, expresada aquí con módulos en lugar de con acciones: la lectura es abierta, la escritura pasa por un conjunto pequeño de funciones con nombre.

Las dos islas comparten estado sin conocerse. Cuando la de Vue llama a anadir, el átomo notifica a sus suscriptores, el adaptador de React traduce esa notificación a un render y la cabecera se actualiza. Ni una línea de coordinación entre frameworks: el store no sabe quién lo escucha y cada adaptador solo sabe traducir una suscripción a su propio modelo de reactividad. Es la arquitectura de la lección uno, llevada al extremo por necesidad.

Este montaje deja además una consecuencia estratégica que las migraciones agradecen: si la verdad vive en un módulo agnóstico y cada isla solo aporta su capa de enlace, puedes reescribir una isla de React a Svelte sin tocar el estado, o introducir un framework nuevo en una página sin migrar nada de lo existente. La arquitectura de islas convierte la elección de framework en una decisión local y reversible, y solo lo consigue porque el estado compartido se negó a pertenecer a ninguno de ellos.

Vale la pena medir el coste de esta solución con números, porque explica por qué no se usa aquí ninguna de las herramientas de los niveles anteriores. Cada isla que importa el store paga su parte del paquete, y en una página con cuatro islas el peso del gestor de estado se cuenta una vez por el módulo compartido más un adaptador diminuto por framework. Con un store de quince kilobytes, la aritmética se vuelve absurda frente al motivo mismo de usar islas, que es enviar poco JavaScript. La restricción de tamaño no es un capricho de la librería: es el requisito que define el problema.