El problema del store global: una acción despierta a todos

Un store global es, por definición, un objeto que muchos observan y que cualquiera puede cambiar. Esa doble propiedad —una fuente de verdad compartida y un canal de escritura abierto— es exactamente lo que hace valioso el patrón, y también lo que crea su tensión de rendimiento más profunda. El núcleo de Redux cabe en cien líneas y su función subscribe no admite matices: guarda una lista de oyentes y, al terminar cada reducción, recorre la lista entera. No hay filtro, no hay clave, no hay ámbito. Cambiar el nombre del usuario despierta al componente que solo mira un contador, y cambiar ese contador despierta al que solo mira el nombre. Este nivel entero nace de esa asimetría, y esta lección la mira de frente antes de estudiar cualquier remedio, porque casi todos los errores de rendimiento con estado global vienen de no haber entendido qué se notifica, a quién y con qué coste.

La asimetría estructural del broadcast

El contrato de un store observable es minúsculo y por eso mismo es rígido. subscribe recibe una función sin argumentos y la guarda; dispatch ejecuta el reducer y después recorre el registro llamando a cada función guardada. Fíjate en lo que ese contrato no dice: el oyente nunca declara qué parte del estado le interesa, y la notificación nunca informa de qué parte cambió. Ambas piezas de información existen —el store sabe qué rama se reemplazó, el componente sabe qué campo lee— pero el canal que las une es demasiado pobre para transportarlas.

// La esencia del store de Redux, sin adornos.
function crearStore(reducer, estadoInicial) {
  let estado = estadoInicial
  const oyentes = new Set()

  return {
    getState: () => estado,
    subscribe(fn) {
      oyentes.add(fn)
      return () => oyentes.delete(fn)
    },
    dispatch(accion) {
      estado = reducer(estado, accion) // una referencia nueva de raiz
      oyentes.forEach((fn) => fn())    // broadcast: sin filtro ni argumentos
      return accion
    },
  }
}

De ahí se deduce el modelo de coste que hay que memorizar: el precio de un despacho no depende de cuánto cambió el estado, sino de cuántos observadores hay. Reemplazar un booleano en una rama diminuta cuesta lo mismo que reescribir medio store, porque el trabajo dominante no es reducir, sino notificar. Es un coste lineal en el número de suscriptores y constante respecto al tamaño del cambio, justo lo contrario de la intuición que traemos de otros sistemas.

Esa asimetría no es un defecto de implementación que una versión futura vaya a corregir: es el precio de la inmutabilidad de raíz. Como cada reducción produce un objeto raíz nuevo, la única comparación barata en el nivel del store —comparar la raíz con ===— siempre da distinto, y por tanto el store nunca puede descartar a nadie. Saber si a un suscriptor concreto le importa exige ejecutar su propia lógica de lectura, y esa lógica vive en el suscriptor, no en el store.

flowchart TD
D[dispatch de una accion] --> R[reducer produce raiz nueva]
R --> N[notificar a TODOS los suscriptores]
N --> S1[selector del componente A]
N --> S2[selector del componente B]
N --> S3[selector del componente C]
S1 --> E1[resultado identico: sin render]
S2 --> E2[resultado distinto: render]
S3 --> E3[resultado identico: sin render]
style E1 fill:#a6e3a1,color:#11111b
style E3 fill:#a6e3a1,color:#11111b
style E2 fill:#fab387,color:#11111b

Las tres amortiguaciones de react-redux

Si cada componente conectado abriera su propia suscripción ingenua y re-renderizara al ser notificado, un store global sería inutilizable a partir de unas decenas de componentes. Lo que hace que el patrón funcione en aplicaciones con miles de nodos es una capa de amortiguación con tres mecanismos distintos, y conviene no confundirlos porque resuelven problemas diferentes.

El tercer mecanismo es el conceptualmente decisivo, y merece una formulación explícita: la librería no consigue notificar solo a los interesados, sino algo distinto y más barato de implementar. Convierte la notificación en una pregunta. En lugar de decidir a quién avisar —imposible sin conocer los intereses—, avisa a todos y deja que cada uno responda si le importa, ejecutando su selector y comparando la respuesta con la de antes. El broadcast sigue ahí; lo que se filtra es su consecuencia.

Reducido a su esqueleto, el hook que hace ese trabajo cabe en unas pocas líneas conceptuales, y verlo desnudo desactiva buena parte de la magia que se le atribuye.

// Version conceptual de useSelector: notificar, ejecutar, comparar, decidir.
function useSelector(selector) {
  const store = useContext(ContextoRedux)
  const anterior = useRef(undefined)

  return useSyncExternalStore(
    store.subscribe,                    // React decide cuando comprobar
    () => {
      const nuevo = selector(store.getState())
      if (Object.is(nuevo, anterior.current)) return anterior.current
      anterior.current = nuevo          // solo aqui se dispara un render
      return nuevo
    },
  )
}

Ese cambio de plano tiene un efecto contable enorme. Un despacho ya no cuesta N renders sino N ejecuciones de selector más los pocos renders cuyo resultado cambió de identidad. Como un selector idiomático es un acceso a propiedad —el trabajo más barato que hace una máquina virtual de JavaScript— y un render es reconciliación más efectos más posible pintado, la diferencia entre ambos costes es de varios órdenes de magnitud. La amortiguación funciona porque traslada el trabajo del lado caro al lado barato de la balanza.

El residuo que no desaparece

Amortiguar no es eliminar, y la parte honesta de esta lección es nombrar lo que sigue costando. Quedan tres residuos. El primero es el propio recorrido: cada despacho ejecuta todos los selectores registrados, y con miles de componentes conectados en pantalla eso es un trabajo real que crece con el tamaño de la interfaz visible, no con el del cambio.

El segundo residuo es el precio de cada pregunta. Un selector barato multiplicado por dos mil suscriptores sigue siendo barato; un selector que ordena o agrupa una lista, multiplicado por dos mil, es una congelación visible. La disciplina que se deriva es contraintuitiva para quien viene de pensar en renders: en un store global, el coste de leer se paga siempre, aunque no cambie nada, mientras que el coste de renderizar solo se paga cuando algo cambia. Por eso el selector caro es más peligroso que el render caro.

El tercer residuo es el que ocupará las tres lecciones siguientes: una respuesta mal formulada. Si un selector devuelve una referencia nueva cada vez que se ejecuta, el corte por igualdad no puede cortar nada y el componente re-renderiza en todos y cada uno de los despachos de la aplicación entera. Ese componente ha vuelto, en la práctica, al mundo sin amortiguación, y lo ha hecho de forma invisible: nada falla, solo va lento.

Conviene además desconfiar de una métrica que se usa mucho y explica poco: el tamaño del store. Un store con megabytes de datos y pocos componentes conectados va perfectamente; un store diminuto leído por dos mil nodos con selectores torpes se arrastra. Lo que se paga en cada despacho no es guardar, sino leer, y el número que predice el coste es la cantidad de suscripciones activas multiplicada por el precio medio de cada una.

El mismo broadcast fuera de Redux

Sería un error archivar todo esto como una peculiaridad de Redux, porque la topología se repite en casi todas las alternativas ligeras. El store de Zustand es el mismo diseño con menos ceremonia: mantiene un conjunto de oyentes, setState los recorre enteros, y el hook ejecuta tu selector y compara el resultado con el anterior por identidad antes de decidir si renderiza. Cambian el tamaño del paquete y la ergonomía; no cambia la aritmética.

Lo interesante es que existen dos estrategias alternativas al broadcast, y ambas están representadas en el ecosistema. La primera es observar los accesos: Valtio envuelve el estado en un proxy que registra qué rutas leyó cada componente durante su render y suscribe a cada uno únicamente a esas rutas. La segunda es declarar las dependencias: Jotai construye un grafo de átomos donde la notificación viaja solo por las aristas que existen, de modo que un cambio en un átomo alcanza exclusivamente a sus derivados y a sus lectores.

Situar el broadcast en ese mapa evita una confusión frecuente. Migrar de Redux a Zustand no resuelve nada de lo que estudia este nivel, porque la clase de coste es idéntica y las técnicas también lo serán; migrar a un modelo de proxy o de grafo sí cambia la clase de problema, pero introduce la suya. Las cuatro lecciones que siguen se aplican, con cambios cosméticos de sintaxis, a cualquier sistema que responda a un cambio preguntando a sus lectores si les importa.