Zustand: el store que es un hook

Si el nivel anterior diagnosticó el desajuste, Zustand es la respuesta que más limpio lo resuelve, y por eso es la más adoptada de la ola ligera en 2026. Su tesis se enuncia en una frase: un store es un hook. No hay Provider que envuelva la app, ni acciones que nombrar, ni reductores que escribir, ni copias inmutables que teclear a mano. Del colectivo Poimandres —los mismos de React Three Fiber—, Zustand toma el modelo de cuatro conceptos de Redux y lo colapsa en uno solo, todo por unos 3KB comprimidos. Este capítulo desmonta cómo lo consigue y dónde están sus filos.

Un store es un hook

La llamada create recibe una función que describe el estado inicial y las acciones, y devuelve un hook. Ese hook es a la vez la puerta de lectura y de escritura, y vive en el ámbito del módulo, no en un árbol de contexto:

import { create } from 'zustand'

type OsoState = {
  osos: number
  aumentar: () => void
  reiniciar: () => void
}

export const useOsoStore = create<OsoState>((set) => ({
  osos: 0,
  aumentar: () => set((state) => ({ osos: state.osos + 1 })),
  reiniciar: () => set({ osos: 0 }),
}))

No hay acciones nombradas ni tipos: las acciones son funciones normales que llaman a set, y set fusiona superficialmente el objeto que devuelves con el estado actual, así que no reescribes las claves que no tocas. La ausencia de Provider no es un truco de comodidad: como el store vive en el módulo, cualquier componente que importe el hook accede al mismo estado sin necesidad de que un ancestro lo provea. La contrapartida es que ese store es un singleton de módulo, lo cual está perfecto en el cliente pero exige cuidado en renderizado de servidor, donde varias peticiones comparten proceso; para ese caso Zustand ofrece crear el store por petición y proveerlo con contexto, pero es la excepción, no la norma.

El selector: suscripción quirúrgica

Usar el hook sin argumentos devolvería el estado entero y re-renderizaría el componente ante cualquier cambio. La clave del rendimiento en Zustand es el selector: una función que extrae solo la porción que te importa, de modo que el componente se re-renderiza únicamente cuando esa porción cambia.

function ContadorOsos() {
  const osos = useOsoStore((state) => state.osos)   // solo re-render si osos cambia
  return <h1>{osos} osos</h1>
}

function Boton() {
  const aumentar = useOsoStore((state) => state.aumentar) // la accion es estable
  return <button onClick={aumentar}>uno mas</button>
}

El detalle fino: el componente que solo selecciona la acción aumentar no se re-renderiza jamás cuando cambia osos, porque la referencia de la función es estable. Esta granularidad —suscribirse a exactamente lo que consumes— es lo que Redux lograba con useSelector pero sin el andamiaje que lo rodeaba. Y a diferencia de la Context API de React, donde cualquier cambio del valor del contexto re-renderiza a todos sus consumidores, aquí la suscripción es por selector, así que un store grande no penaliza a los componentes que solo miran una esquina de él.

Middleware: persistencia, devtools e Immer

Zustand mantiene el núcleo minúsculo y deja las capacidades avanzadas como middleware opcional que envuelve la función del store. El más usado es persist, que sincroniza el estado con localStorage de forma transparente:

import { persist } from 'zustand/middleware'

export const useAjustes = create(
  persist(
    (set) => ({
      tema: 'oscuro',
      alternar: () => set((s) => ({ tema: s.tema === 'oscuro' ? 'claro' : 'oscuro' })),
    }),
    { name: 'ajustes' },   // clave en localStorage
  ),
)

Se componen anidándolos, y esa composición es la razón de que el núcleo quepa en 3KB: pagas peso solo por lo que activas.

Organizar a escala: slices y estado transitorio

El miedo razonable ante tanta libertad es que un store crezca hasta volverse un cajón desastre global. El patrón idiomático para evitarlo son los slices: fragmentos de estado y acciones definidos en funciones separadas que reciben set y get, y que se combinan en un único create. Modularizas sin fragmentar el store ni perder la suscripción por selector.

const crearPeces = (set) => ({
  peces: 0,
  pescar: () => set((s) => ({ peces: s.peces + 1 })),
})
const crearOsos = (set) => ({
  osos: 0,
  cazar: () => set((s) => ({ osos: s.osos + 1 })),
})

export const useStore = create((...a) => ({
  ...crearPeces(...a),
  ...crearOsos(...a),
}))

Para el otro extremo del espectro —valores que cambian muchas veces por segundo, como la posición del ratón o un frame de animación— re-renderizar React en cada cambio sería suicida. Ahí entran las actualizaciones transitorias: te suscribes al store fuera del ciclo de render y aplicas el cambio a mano, sin provocar re-render.

// Reaccionar sin re-render: ideal para canvas, animaciones o valores de alta frecuencia.
const unsub = useStore.subscribe((state) => {
  pintarEnCanvas(state.osos)   // corre en cada cambio, sin re-renderizar React
})

import { useShallow } from 'zustand/shallow'

// Correcto: comparacion superficial, re-render solo si a o b cambian.
const { a, b } = useAjustes(useShallow((s) => ({ a: s.a, b: s.b })))