Fuera de React: código plano, transitorio y SSR

Toda la lección primera insistía en que create devuelve dos cosas: un hook y, adherida a él, la API completa del store vanilla. Hasta ahora hemos vivido en la primera cara. La segunda es la que convierte a Zustand en algo más que una librería de React: un store al que se puede leer y escribir desde un interceptor de fetch, un manejador de teclado global, un worker o un test, sin que exista un árbol de componentes. Y es también la cara que esconde el único defecto estructural de la librería, el que ninguna cantidad de selectores arregla: si el store vive en el ámbito del módulo y el módulo vive en un proceso de Node que atiende a mil usuarios, el store es de los mil. Esta lección cubre las dos mitades, la potencia y la fuga.

El store sin React

Los tres métodos de la API vanilla cubren el ciclo completo y no requieren nada del entorno. getState devuelve el estado vigente sin suscribir a nadie; setState escribe con la misma semántica de fusión superficial que el set interno; subscribe registra un oyente y devuelve la función para darlo de baja. Con eso basta para integrar el store con cualquier cosa.

// un interceptor de red que lee la sesion sin ser un componente
export async function apiFetch(url: string, init?: RequestInit) {
  const { token, salir } = useSesion.getState()
  const res = await fetch(url, {
    ...init,
    headers: { ...init?.headers, Authorization: `Bearer ${token}` },
  })
  if (res.status === 401) salir()   // escribir el store desde codigo plano
  return res
}

Este patrón resuelve de un plumazo la clase entera de problemas que en Redux exigía inyectar el store en el módulo de la API o pasarlo por parámetro. Pero conviene enunciar la regla que lo mantiene sano: getState es correcto en código que se ejecuta por un evento, y es un error dentro del cuerpo de un componente. En pleno render, leer con getState no crea suscripción, así que el componente mostrará un valor que puede quedar obsoleto sin que nada lo despierte, y además rompe las garantías del renderizado concurrente. Dentro de React, el selector; fuera de React, getState.

Actualizaciones transitorias: reaccionar sin renderizar

Hay una categoría de estado que rompe el modelo de render por cambio: la posición del ratón, el desplazamiento de la página, el progreso de una animación. Suscribir un componente a esos valores significa reconciliar a la frecuencia de refresco de la pantalla, y ninguna optimización de selector lo salva porque el valor sí cambia de verdad. La solución idiomática se llama actualización transitoria: suscribirse fuera del ciclo de render y aplicar el efecto a mano.

function Cursor() {
  const ref = useRef<HTMLDivElement>(null)

  useEffect(() => {
    // subscribeWithSelector permite escuchar solo una porcion
    return usePuntero.subscribe(
      (s) => s.x,
      (x) => { if (ref.current) ref.current.style.transform = `translateX(${x}px)` },
      { fireImmediately: true },
    )
  }, [])

  return <div ref={ref} className="cursor" />
}

Repara en la geometría del truco: la suscripción se registra en un efecto, se limpia devolviendo la propia función de baja, y el valor viaja del store al DOM sin pasar por el estado de React ni por sus propiedades. El componente sigue siendo el dueño del nodo —lo creó y lo destruirá— pero delega la actualización de un atributo concreto a un canal paralelo. Es exactamente el mismo compromiso que hacen las librerías de animación al escribir estilos fuera del reconciliador, con la diferencia de que aquí la fuente del valor es tu propio store y no un motor opaco.

El componente se renderiza una sola vez en toda su vida. El store sigue actualizándose a la frecuencia que haga falta, pero React nunca se entera, porque el puente entre el dato y el DOM es una escritura directa sobre un nodo que ya existe.

El singleton es una fuga entre peticiones

En el navegador, un store por módulo es un store por usuario, porque cada pestaña tiene su propio entorno. En el servidor, la aritmética es otra: el módulo se evalúa una vez por proceso y el proceso atiende peticiones de gente distinta. Un store creado con create en el ámbito del módulo es, en ese contexto, una variable global compartida entre usuarios. Si una petición escribe el nombre de quien inició sesión, la siguiente lo lee.

flowchart TD
A[proceso de Node con el modulo ya evaluado] --> B[store unico creado al importar]
B --> C[peticion de la usuaria A escribe su sesion]
B --> D[peticion del usuario B lee la sesion de A]
A --> E[alternativa: fabrica por peticion]
E --> F[store nuevo dentro de un contexto de React]
style D fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b

Hay un segundo problema, menos grave pero más ruidoso, y es el snapshot. useSyncExternalStore exige una función que devuelva el estado en el servidor, y debe ser estable: si en cada llamada devolviera algo distinto, React no podría comparar. Por eso existe getInitialState, que Zustand usa como snapshot de servidor mientras getState sirve al cliente. La consecuencia práctica es que el HTML se genera siempre con el estado inicial del código, así que cualquier estado que solo el cliente conoce —lo rehidratado por persist, lo leído de localStorage— producirá un desajuste de hidratación si lo pintas en el primer render.

Store por petición: fábrica y contexto

La solución correcta es dejar de crear el store al importar el módulo y crearlo en una fábrica que se invoca una vez por petición en el servidor y una vez por vida de la aplicación en el cliente. Como ya no hay un singleton al que importar, hace falta un canal para repartirlo, y ese canal es un contexto de React. Es el único uso legítimo de un provider en Zustand, y merece subrayarse que el contexto transporta la referencia al store, que nunca cambia, y no el estado: por eso no reaparece el problema de rendimiento del contexto clásico, y la suscripción sigue siendo por selector.

'use client'
import { createContext, useContext, useRef, type ReactNode } from 'react'
import { createStore } from 'zustand/vanilla'
import { useStore } from 'zustand'

type TiendaStore = ReturnType<typeof crearTiendaStore>

export const crearTiendaStore = (inicial?: Partial<Tienda>) =>
  createStore<Tienda>()((set) => ({ ...estadoBase, ...inicial, /* acciones */ }))

const Ctx = createContext<TiendaStore | null>(null)

export function TiendaProvider({ children, inicial }: { children: ReactNode; inicial?: Partial<Tienda> }) {
  const ref = useRef<TiendaStore>()
  if (!ref.current) ref.current = crearTiendaStore(inicial)   // una sola vez por arbol
  return <Ctx.Provider value={ref.current}>{children}</Ctx.Provider>
}

export function useTienda<T>(sel: (s: Tienda) => T): T {
  const store = useContext(Ctx)
  if (!store) throw new Error('useTienda fuera de TiendaProvider')
  return useStore(store, sel)
}

Con persist en la pila, la fábrica por petición exige un cuidado extra: en el servidor no existe localStorage, así que hay que activar skipHydration y rehidratar en el cliente dentro de un efecto, o dar un almacén de no operación cuando window no está definido. Y si varias pestañas comparten la misma clave de persistencia, el estado sembrado por el servidor y el guardado en el navegador compiten; decidir cuál gana es una decisión de producto, no de infraestructura, y conviene escribirla en el merge de persist en lugar de dejarla al azar del orden de ejecución.

Los dos detalles que suelen fallar están en el proveedor. El primero es crear el store con useState o directamente en el cuerpo del componente: en modo estricto y con render concurrente, eso puede construirlo dos veces, y la guarda sobre una referencia lo evita sin efectos. El segundo es el parámetro inicial, que es la vía por la que el servidor siembra el store con datos que ya conoce —la sesión, la configuración regional— y que el cliente hereda sin volver a pedirlos.