Selectores: la suscripción es del que lee

En Redux el selector era una comodidad para leer del store sin acoplarse a su forma. En Zustand es algo mucho más literal: el selector es la suscripción. Cuando escribes useCarrito((s) => s.cupon) no estás pidiendo un dato, estás declarando un contrato con el store que dice avísame solo si esta expresión cambia de valor. Todo el rendimiento de la librería descansa en ese contrato, y casi todos sus bugs de rendimiento nacen de firmarlo mal: de devolver un objeto nuevo en cada llamada, de calcular dentro del selector algo que no debería calcularse ahí, o de suscribirse al store entero por pereza. Esta lección desmonta la mecánica exacta de la comparación para que el contrato lo escribas con los ojos abiertos.

El contrato: selector, snapshot y Object.is

El hook que devuelve create delega en useSyncExternalStore, la API que React 18 introdujo precisamente para consumir fuentes externas sin desgarrar la interfaz durante el renderizado concurrente. Su funcionamiento es simple de enunciar y decisivo de comprender: React se suscribe al store, y cada vez que el store notifica, vuelve a ejecutar tu selector sobre el nuevo estado y compara el resultado con el anterior usando Object.is. Si son iguales, no hay render y ni siquiera se marca el componente. Si difieren, se programa el render.

flowchart TD
A[una accion llama a set] --> B[el store notifica a todos los suscriptores]
B --> C[React ejecuta el selector de cada componente]
C --> D{Object.is del resultado nuevo y el viejo}
D -->|iguales| E[sin render]
D -->|distintos| F[render de ese componente]
style E fill:#a6e3a1,color:#11111b
style F fill:#f9e2af,color:#11111b

De ese diagrama salen tres consecuencias que gobiernan todo lo demás. Primera: el selector corre en cada cambio del store, para cada componente suscrito, así que debe ser barato y puro. Segunda: el criterio es la identidad, no la igualdad estructural, y para valores primitivos ambas coinciden pero para objetos no. Tercera: no existe suscripción por clave sino por resultado, de modo que la granularidad no la fija la forma del store sino la expresión que escribes.

function Cupon() {
  const cupon = useCarrito((s) => s.cupon)           // primitivo: Object.is basta
  const aplicar = useCarrito((s) => s.aplicarCupon)  // funcion estable: nunca re-renderiza
  return <input value={cupon ?? ''} onChange={(e) => aplicar(e.target.value)} />
}

Esa tercera consecuencia es la más liberadora y la que más cuesta interiorizar viniendo de Redux, donde la normalización del estado era en parte una técnica para hacer posibles las lecturas eficientes. Aquí la eficiencia no depende de cómo hayas guardado los datos sino de qué pide cada lector, de modo que un store con una forma cómoda para escribir no penaliza a quien lee, siempre que el selector proyecte algo que ya existe. La forma del estado vuelve a poder decidirse por el dominio y no por el rendimiento.

Llamar al hook sin selector devuelve el estado completo y equivale a suscribirse a todo: como cada set produce un objeto de estado nuevo, la comparación por identidad falla siempre y el componente se re-renderiza ante cualquier cambio del store, aunque no use nada de lo que cambió. No es un error de la librería, es la consecuencia coherente del contrato.

El fallo de identidad y useShallow

El problema aparece en cuanto un componente necesita dos campos a la vez y la mano escribe lo natural: un selector que devuelve un objeto literal con ambos. Ese objeto es nuevo en cada ejecución, Object.is lo declara distinto del anterior sin mirar su contenido, y el componente se re-renderiza en absolutamente todos los cambios del store. En la versión 5 el síntoma llegó a ser más ruidoso que un render de más: React puede detectar que el snapshot no es estable y lanzar el aviso de que la fuente externa devuelve un valor distinto en cada llamada, con un bucle de renders como consecuencia.

// mal: objeto nuevo en cada llamada, la identidad nunca coincide
const { cupon, lineas } = useCarrito((s) => ({ cupon: s.cupon, lineas: s.lineas }))

Hay dos reparaciones legítimas. La primera y preferible es no construir nada: llamar al hook dos veces con dos selectores atómicos. Suena a desperdicio y no lo es, porque cada llamada es una comparación de un primitivo o de una referencia estable, y React agrupa los renders resultantes en uno solo. La segunda, cuando de verdad necesitas un objeto —porque los campos son muchos o vienen de un cálculo—, es useShallow, que memoiza el último resultado y lo compara clave a clave en lugar de por referencia, devolviendo el objeto anterior si el contenido no cambió.

import { useShallow } from 'zustand/react/shallow'

const { cupon, lineas } = useCarrito(
  useShallow((s) => ({ cupon: s.cupon, lineas: s.lineas })),
)

// tambien resuelve el clasico: derivar un array de claves
const skus = useCarrito(useShallow((s) => s.lineas.map((l) => l.sku)))

Igualdad a medida: createWithEqualityFn

Hasta la versión 4, el hook aceptaba un segundo argumento con una función de igualdad, y era habitual escribir useStore(selector, shallow). La versión 5 lo eliminó del núcleo por una razón de fondo: useSyncExternalStore no admite comparadores personalizados, así que soportarlo obligaba a mantener una implementación paralela con sus propias garantías de concurrencia. Esa implementación no desapareció, se mudó a zustand/traditional, y ahí sigue disponible para quien la necesite.

import { createWithEqualityFn } from 'zustand/traditional'
import { shallow } from 'zustand/shallow'

export const useCarrito = createWithEqualityFn<Carrito>()(
  (set) => ({ /* estado y acciones */ }),
  shallow,   // igualdad por defecto para todos los selectores de este store
)

Merece la pena entender qué se gana y qué se cede al elegir esa vía. Se gana no repetir el envoltorio en cada componente, lo que al migrar una base de código grande desde la versión 4 evita tocar cientos de llamadas. Se cede visibilidad: la política de comparación deja de estar escrita junto al selector y pasa a vivir en la definición del store, de modo que quien lea un componente ya no puede saber, solo mirándolo, cuándo se re-renderiza. Y se cede también la implementación estándar, porque zustand/traditional mantiene su propio puente en lugar de apoyarse íntegramente en useSyncExternalStore. Para código nuevo, useShallow explícito es la elección por defecto; createWithEqualityFn es una herramienta de migración con fecha de caducidad.

Derivar sin pagarlo en cada render

El error más caro no es el de identidad sino el conceptual: usar el selector como si fuera un createSelector de Reselect. El selector de Zustand no memoiza nada por sí mismo y se ejecuta una vez por componente y por notificación, de modo que ordenar mil elementos dentro de él significa ordenarlos mil veces por segundo si el store es activo, aunque el resultado sea siempre idéntico. Hay tres salidas, y elegir entre ellas es una decisión de diseño, no de estilo.

La primera es derivar en el momento de escribir: si el total del carrito es función de las líneas, calcúlalo en la acción que las modifica y guárdalo como un campo más. Duplicas información, pero el coste se paga una vez por escritura en lugar de una vez por lectura, y en una interfaz típica hay órdenes de magnitud más lecturas. La segunda es memoizar aparte, envolviendo el cálculo con useMemo sobre el valor atómico que ya seleccionaste, o con una fábrica de selectores memoizados si la derivación se comparte entre componentes. La tercera es no derivar en React en absoluto: para valores de alta frecuencia —posición del ratón, progreso de una animación— la respuesta correcta es suscribirse fuera del ciclo de render, y ese es el terreno de la quinta lección.

// derivar barato sobre un valor ya seleccionado
const lineas = useCarrito((s) => s.lineas)
const total = useMemo(() => lineas.reduce((a, l) => a + l.cantidad, 0), [lineas])

Cuando la misma proyección se repite en varios componentes, extraerla a una fábrica de selectores mantiene la lógica en un solo sitio y hace que el punto de suscripción sea evidente al leer el componente. La fábrica devuelve el selector; la memoización, si el cálculo la merece, se aplica sobre el resultado y no dentro de la proyección.

// selectores compartidos: la forma del store queda encapsulada en un modulo
export const selLineas = (s: Carrito) => s.lineas
export const selCupon = (s: Carrito) => s.cupon
export const selLineaPorSku = (sku: string) => (s: Carrito) =>
  s.lineas.find((l) => l.sku === sku)

Ese último caso esconde un matiz importante: find devuelve una referencia que el store ya guarda, así que la comparación por identidad funciona y no hace falta ningún envoltorio. La distinción decisiva no es si el selector contiene una llamada a un método de array, sino si el valor devuelto es una referencia preexistente o un objeto recién construido. Localizar un elemento que ya está en el store es barato porque devuelve su referencia; filtrar, mapear o reducir construye estructuras nuevas y rompe la identidad en cada llamada.