create: el store que es un hook

Zustand se presenta con un eslogan que suena a marketing y resulta ser una descripción literal: el store es un hook. Pero esa frase esconde una arquitectura de dos capas que casi nadie disecciona. Debajo hay un store vanilla —un closure con un objeto de estado, un conjunto de suscriptores y tres métodos— que no sabe absolutamente nada de React. Encima, una función que convierte ese store en un hook mediante useSyncExternalStore. Entender esa separación no es curiosidad arqueológica: explica por qué no hace falta provider, por qué las acciones son estables entre renders, por qué el estado sobrevive al desmontaje de todos sus consumidores y por qué el store es un singleton de módulo que te morderá en el servidor si no lo ves venir. El nivel entero se construye sobre esta lección.

Dos capas: un store vanilla y un hook encima

La librería que instalas contiene dos piezas separadas que create te sirve fusionadas. La primera es createStore, exportada desde zustand/vanilla: recibe un inicializador y devuelve un objeto con getState, setState, subscribe y getInitialState. Es un patrón observador clásico, de unas pocas decenas de líneas, sin ninguna dependencia de React. La segunda es useStore, exportada desde zustand/react: recibe ese store y un selector, y se conecta al árbol de React mediante useSyncExternalStore. La función create no hace más que llamar a la primera y devolver la segunda ya atada, con la API vanilla adherida como propiedades del propio hook.

flowchart LR
A[create con inicializador] --> B[store vanilla getState setState subscribe]
B --> C[useSyncExternalStore]
C --> D[hook con selector en el componente]
B --> E[codigo plano fuera de React]
style B fill:#a6e3a1,color:#11111b
style D fill:#89b4fa,color:#11111b
style E fill:#f9e2af,color:#11111b

Esa doble salida es lo que hace a Zustand distinto de un contexto: el estado no vive en el árbol, vive en un módulo, y React es solo uno de sus consumidores posibles. El inicializador que le pasas recibe tres argumentos —set, get y la propia API del store— y devuelve el objeto que será el estado inicial, acciones incluidas.

import { create } from 'zustand'

type Linea = { sku: string; cantidad: number }

type Carrito = {
  lineas: Linea[]
  cupon: string | null
  anadir: (l: Linea) => void
  aplicarCupon: (codigo: string) => void
}

export const useCarrito = create<Carrito>()((set, get) => ({
  lineas: [],
  cupon: null,
  anadir: (l) => set((s) => ({ lineas: [...s.lineas, l] })),
  aplicarCupon: (codigo) => {
    if (get().lineas.length === 0) return   // lee el estado vigente, no uno capturado
    set({ cupon: codigo })
  },
}))

set: fusionar, reemplazar y no notificar de más

set acepta o bien un objeto parcial, o bien una función que recibe el estado previo y devuelve ese parcial. En ambos casos el resultado se fusiona superficialmente sobre el estado actual: las claves que no mencionas se conservan tal cual. Superficialmente significa exactamente eso, un solo nivel: si tu estado tiene un objeto anidado y devuelves una versión parcial de él, la clave entera se sustituye y pierdes los campos que no repetiste. Ese límite es la razón de existir del middleware immer, que veremos en la tercera lección.

// fusion superficial: cupon se conserva
set({ lineas: [] })

// segundo argumento true: reemplazo total del estado
set({ lineas: [], cupon: null, anadir, aplicarCupon }, true)

// anidamiento profundo sin immer: propagacion a mano
set((s) => ({ envio: { ...s.envio, pais: 'ES' } }))

El segundo argumento booleano fuerza el reemplazo en vez de la fusión, y es una escopeta cargada: si reemplazas el estado entero olvidando incluir las acciones, las borras del store y cualquier componente que las tuviera seleccionadas apuntará a undefined. Existe para reinicios deliberados y para tests, no para el uso diario.

Hay un detalle de rendimiento que conviene interiorizar ya. Cuando llamas a set, el store construye el siguiente estado y notifica a todos sus suscriptores; no compara campo a campo antes de avisar. Quien filtra es cada suscriptor con su selector, comparando su porción con Object.is. La consecuencia práctica es que un set que escribe el mismo valor que ya había no provoca ni un solo re-render, porque ningún selector detecta cambio, pero sí recorre la lista de suscriptores. Con cientos de componentes suscritos y actualizaciones a sesenta hercios, ese recorrido deja de ser gratis, y ahí es donde entran las suscripciones fuera de React de la última lección.

get y las acciones que viven dentro del estado

La decisión de diseño más subversiva de Zustand es que las acciones no son un artefacto aparte: son campos del propio estado, funciones almacenadas junto a los datos que modifican. Eso tiene dos consecuencias enormes. La primera es de legibilidad: el estado y sus transiciones se leen de un vistazo, sin saltar entre un archivo de tipos, uno de creadores y uno de reductores. La segunda es de rendimiento: como esas funciones se definen una sola vez, al crear el store, y nunca se vuelven a escribir con set, su referencia es estable para siempre. Un componente que solo selecciona una acción no se re-renderiza jamás.

get es la puerta a ese estado vigente desde dentro de una acción. Es importante entender por qué no basta con la forma funcional de set: set((s) => ...) te da el estado en el instante de la escritura, pero una acción asíncrona necesita leer el estado después de un await, cuando el mundo ya ha cambiado. Capturar el estado en una variable antes de esperar es la fuente clásica del closure obsoleto.

export const useCarrito = create<Carrito>()((set, get) => ({
  lineas: [],
  cupon: null,
  anadir: (l) => set((s) => ({ lineas: [...s.lineas, l] })),
  aplicarCupon: async (codigo) => {
    const ok = await validarCupon(codigo)
    if (!ok) return
    if (get().lineas.length === 0) return   // el carrito pudo vaciarse durante el await
    set({ cupon: codigo })
  },
}))

Existe un debate menor sobre dónde colocar las acciones, y conviene zanjarlo con criterio en vez de con gusto. Agruparlas bajo una clave actions ordena el objeto y permite seleccionarlas todas de golpe con un solo selector estable, pero rompe la fusión superficial en cuanto quieras modificar una sola y obliga a propagar el grupo entero. Dejarlas al mismo nivel que los datos, que es la recomendación oficial, mantiene la escritura trivial a cambio de un objeto más plano. La tercera vía —definir las acciones fuera del inicializador, como funciones del módulo que llaman a useCarrito.setState— separa datos de comportamiento y deja el estado serializable de arriba abajo, pero ata cada acción al store concreto que importa, así que se lleva mal con la fábrica por petición de la última lección.

Singleton de módulo: la libertad y su factura

Que no haya provider significa que el store se crea cuando el módulo se evalúa por primera vez, y que a partir de ahí hay exactamente uno por proceso. En el navegador eso es puro beneficio: cualquier archivo que importe el hook accede al mismo estado sin que un ancestro tenga que proveerlo, no hay cascadas de re-render por cambio de valor de contexto, y el estado sobrevive al desmontaje de todos sus consumidores. Pero un singleton es un estado global con todo lo que la expresión implica, y la factura llega en dos escenarios concretos.

El primero son los tests: si el módulo se importa una vez y el test runner comparte el registro de módulos entre casos, el estado del primer test contamina al segundo. La solución idiomática es capturar el estado inicial y restaurarlo en un gancho de limpieza.

const inicial = useCarrito.getInitialState()

afterEach(() => {
  useCarrito.setState(inicial, true)   // reemplazo total: vuelve al punto cero
})

El segundo es el renderizado en servidor, donde el proceso de Node atiende muchas peticiones y todas comparten los módulos ya evaluados. Un store de módulo se convierte allí en una variable global compartida entre usuarios distintos, con el resultado evidente. La respuesta —crear el store por petición y proveerlo con un contexto— es la única situación en la que Zustand recupera el provider, y es el tema de la quinta lección de este nivel.