Slices: partir el store sin romper el store

La libertad que hace agradable a Zustand es también su riesgo estructural: como nada te obliga a organizar el store, un archivo que empezó con tres campos termina con setenta y una función de trescientas líneas que nadie se atreve a tocar. El patrón slice es la respuesta idiomática, y conviene decir desde el principio qué no es: no crea varios stores, no crea espacios de nombres y no aísla nada en tiempo de ejecución. Lo único que hace es partir el inicializador en funciones que reciben el mismo set y el mismo get, y cuyos objetos se funden en uno solo. La modularidad que ganas es de código fuente, no de estado, y entender esa distinción es la diferencia entre usar slices con criterio y creer que te protegen de algo que no te protegen.

La mecánica: una fusión de objetos, nada más

Un slice es una función con la misma firma que el inicializador —recibe set, get y api— que devuelve solo su porción del estado y sus acciones. Combinarlos consiste en propagar los mismos argumentos a todas las funciones creadoras y fundir sus resultados en un objeto. La expresión idiomática usa el operador de resto para no repetir los tres parámetros.

import { create } from 'zustand'

const crearAuth = (set, get) => ({
  usuario: null,
  entrar: (u) => set({ usuario: u }),
  salir: () => set({ usuario: null }),
})

const crearCarrito = (set, get) => ({
  lineas: [],
  anadir: (l) => set((s) => ({ lineas: [...s.lineas, l] })),
})

export const useTienda = create((...a) => ({
  ...crearAuth(...a),
  ...crearCarrito(...a),
}))

Conviene ver con precisión qué ha ocurrido aquí, porque de ello se derivan todas las trampas del patrón. El estado resultante es plano: usuario y lineas conviven al mismo nivel, no hay un objeto auth ni un objeto carrito. Los slices comparten el mismo set, de modo que una acción de crearAuth puede escribir perfectamente un campo de crearCarrito sin que nada se lo impida. Y comparten el mismo get, así que cualquier slice ve el estado completo. La separación existe en los archivos y en tu cabeza; en memoria hay un único objeto.

flowchart TD
A[crearAuth con set get api] --> D[fusion de objetos]
B[crearCarrito con set get api] --> D
C[crearUI con set get api] --> D
D --> E[un unico estado plano en un unico store]
E --> F[selectores que atraviesan cualquier slice]
style D fill:#f9e2af,color:#11111b
style E fill:#a6e3a1,color:#11111b

Que el estado sea plano tiene una consecuencia positiva que a menudo se pasa por alto: los selectores no se enteran de la partición. Un componente puede leer usuario y lineas en el mismo selector, y un slice nuevo no obliga a tocar ni un consumidor. La partición es reversible, algo que casi nunca ocurre cuando se elige la alternativa de montar varios stores independientes.

Tipar la intersección con StateCreator

En TypeScript cada slice necesita declarar dos cosas distintas: qué devuelve él y en qué store completo va a vivir, porque su set y su get operan sobre el store entero, no sobre su porción. StateCreator expresa justo eso con cuatro parámetros genéricos: el estado completo, la tupla de mutadores aplicados por fuera, la tupla de los aplicados por dentro y el tipo devuelto por esta función concreta.

import { create, type StateCreator } from 'zustand'

export type AuthSlice = {
  usuario: string | null
  entrar: (u: string) => void
  salir: () => void
}

export type CarritoSlice = {
  lineas: Linea[]
  anadir: (l: Linea) => void
  vaciarSiSinSesion: () => void
}

export type Tienda = AuthSlice & CarritoSlice   // la interseccion es el store

export const crearAuth: StateCreator<Tienda, [], [], AuthSlice> = (set) => ({
  usuario: null,
  entrar: (u) => set({ usuario: u }),
  salir: () => set({ usuario: null }),
})

export const useTienda = create<Tienda>()((...a) => ({
  ...crearAuth(...a),
  ...crearCarrito(...a),
}))

Al añadir middleware, la tupla de mutadores deja de estar vacía y hay que escribirla en el segundo parámetro de cada slice que reciba un set alterado. Si usas immer, todos lo reciben.

type ConImmer = [['zustand/immer', never]]

export const crearCarrito: StateCreator<Tienda, ConImmer, [], CarritoSlice> = (set, get) => ({
  lineas: [],
  anadir: (l) => set((s) => { s.lineas.push(l) }),
  vaciarSiSinSesion: () => {
    if (get().usuario === null) set((s) => { s.lineas = [] })   // lee otro slice
  },
})

Fronteras: dónde cortar y cuánto dejar cruzar

Hay una variante que aparece en cuanto un slice necesita configuración de arranque: convertir la función creadora en una fábrica que recibe parámetros y devuelve el StateCreator. Cuesta un nivel más de paréntesis y resuelve limpiamente el sembrado de estado inicial desde el servidor o desde un test.

export const crearCarrito =
  (inicial: Linea[] = []): StateCreator<Tienda, [], [], CarritoSlice> =>
  (set, get) => ({
    lineas: inicial,
    anadir: (l) => set((s) => ({ lineas: [...s.lineas, l] })),
    vaciarSiSinSesion: () => {
      if (get().usuario === null) set({ lineas: [] })
    },
  })

export const useTienda = create<Tienda>()((...a) => ({
  ...crearAuth(...a),
  ...crearCarrito(lineasDelServidor)(...a),
}))

El criterio de corte que mejor envejece no es técnico sino de propiedad: un slice debe agrupar el estado que cambia por las mismas razones y a la misma cadencia. La sesión cambia al entrar y al salir; el carrito, con cada interacción de compra; el tema, casi nunca. Cortar así hace que las lecturas cruzadas sean pocas y direccionales, y una dirección clara —el carrito consulta la sesión, la sesión ignora el carrito— es lo que impide que el grafo se convierta en una maraña.

Cuando la lectura cruzada deja de bastar y un slice necesita reaccionar a los cambios de otro, la respuesta no es más get dentro de las acciones sino una suscripción explícita con subscribeWithSelector, declarada fuera de ambos slices. Así la relación queda escrita en un solo lugar en vez de repartida en las acciones de los dos, que es la diferencia entre un acoplamiento documentado y uno emergente.