Redux es agnóstico: el store es JavaScript puro

Durante diecisiete niveles hemos hablado de Redux como si fuese una pieza de React, y esa costumbre esconde el hecho más importante de la librería: el store de Redux no contiene una sola línea de código de React. Es un objeto de JavaScript con tres métodos —getState, dispatch y subscribe— que podrías ejecutar en Node, en un worker, en una extensión de navegador o en una aplicación escrita en Vue sin cambiar absolutamente nada. Lo que llamamos la integración con React vive entero en un paquete aparte, react-redux, y su trabajo se reduce a traducir la suscripción del store al ciclo de render de una vista concreta. Este nivel consiste en soltar el andamio y mirar el patrón desnudo, y empieza por el reconocimiento más incómodo para quien aprendió los dos a la vez: React nunca fue necesario.

El store no sabe que existe React

Abre el código fuente de Redux y cuenta las dependencias: no hay ninguna. El paquete entero son unos cientos de líneas que construyen un objeto con una función que devuelve el estado, otra que recibe acciones y otra que registra oyentes. No importa nada, no conoce el DOM, no sabe qué es un componente. Esta pobreza deliberada no es un accidente de implementación sino la decisión de diseño que explica el nivel entero: al no acoplarse a ninguna vista, Redux se volvió portable a todas.

Esa superficie mínima tiene una consecuencia que conviene enunciar sin adornos: el patrón Flux es independiente de la tecnología de renderizado. El flujo unidireccional que estudiamos en el Nivel 1 —acción, reducer, estado nuevo, notificación— ocurre entero dentro del store, antes de que ninguna vista se entere. La vista es un suscriptor más, no un participante privilegiado del ciclo. Y si es un suscriptor más, puede ser cualquier cosa capaz de ejecutar una función cuando la avisan.

La lista de entornos donde ese objeto funciona sin cambios es más larga de lo que sugiere la costumbre. Un proceso de Node que orquesta un flujo de datos, un worker que mantiene el estado de una simulación fuera del hilo principal, el proceso principal de una aplicación de Electron, el servicio de fondo de una extensión de navegador, un juego que pinta sobre un lienzo, incluso un programa de terminal: en todos ellos el store se crea igual, se despacha igual y se suscribe igual, porque en ninguno de ellos hay nada que Redux necesite del entorno. Cuando alguien dice que Redux es pesado para su caso, casi siempre se refiere al coste del paquete de integración y de las convenciones alrededor, no a los dos kilobytes del núcleo.

Un contador sin framework

La demostración más contundente cabe en treinta líneas. Aquí está el patrón completo —store, acciones, reducer, suscripción y render— gobernando dos botones y un texto sobre el DOM desnudo, sin React, sin build, sin componentes.

import { createStore } from 'redux'

type Estado = { valor: number }
type Accion = { type: 'incrementar' } | { type: 'decrementar' }

function contador(estado: Estado = { valor: 0 }, accion: Accion): Estado {
  switch (accion.type) {
    case 'incrementar': return { valor: estado.valor + 1 }
    case 'decrementar': return { valor: estado.valor - 1 }
    default: return estado
  }
}

const store = createStore(contador)

// la vista es una funcion que lee el estado y pinta: nada mas
const salida = document.getElementById('valor')!
function render() {
  salida.textContent = String(store.getState().valor)
}

// el enlace completo: suscribirse y pintar una vez al arrancar
store.subscribe(render)
render()

document.getElementById('mas')!.onclick = () => store.dispatch({ type: 'incrementar' })
document.getElementById('menos')!.onclick = () => store.dispatch({ type: 'decrementar' })

Antes de analizarlo, fíjate en la anatomía: las primeras quince líneas son el patrón —tipos, reducer, store— y son transferibles tal cual a cualquier entorno; las últimas ocho son la vista, y son lo único que habría que reescribir si mañana cambiaras de tecnología. Esa proporción no es casual y se mantiene en aplicaciones reales: la parte agnóstica es la mayor y la más valiosa, y la parte atada al framework es fina y sustituible.

Merece la pena detenerse en lo que no aparece en ese fragmento. No hay Provider, porque el store es una variable del módulo y cualquiera que lo importe lo tiene. No hay useSelector, porque leer es llamar a getState. No hay connect, porque conectar es llamar a subscribe. Las tres piezas que en React parecen fundamentales resultan ser andamiaje para un problema que en el DOM plano no existe: cómo hacer que un árbol de componentes con render declarativo reaccione a un objeto mutable de fuera.

flowchart TD
ST[store de redux en javascript puro] --> API[getState dispatch subscribe]
API --> EV[capa de enlace vanilla]
API --> ER[capa de enlace react-redux]
API --> EO[capa de enlace de otro framework]
EV --> D1[nodos del dom]
ER --> D2[componentes de react]
EO --> D3[componentes de vue o svelte]
style ST fill:#f38ba8,color:#11111b
style API fill:#f9e2af,color:#11111b
style EV fill:#a6e3a1,color:#11111b
style ER fill:#89b4fa,color:#11111b

La capa de enlace es lo único que cambia

Si el store es idéntico en todas partes, la pregunta interesante es qué hace exactamente el paquete que lo conecta a una vista. La respuesta de react-redux tiene tres partes, y ninguna trata sobre gestión de estado. La primera es la distribución: el Provider mete el store en el contexto para no obligar a importarlo en cada archivo, algo irrelevante cuando el módulo se importa directamente. La segunda es la selección: useSelector ejecuta tu función sobre el estado y decide si el resultado cambió, para no volver a renderizar cuando la porción que te interesa sigue igual. La tercera, y la más sutil, es la sincronización con el modo concurrente de React mediante useSyncExternalStore, que garantiza que un componente no lea un estado a medio actualizar mientras el renderizador interrumpe y reanuda trabajo.

El mismo store, sin tocar una línea, funciona en un entorno donde ni siquiera hay pantalla. Este fragmento es un proceso de Node que reacciona a eventos y guarda un registro, y usa el patrón por sus garantías de trazabilidad, no por su relación con ninguna interfaz.

// mismo store, cero vista: la trazabilidad es util aunque no haya pantalla
const store = createStore(contador)

// el suscriptor ahora es un registro, no un nodo del dom
store.subscribe(() => {
  console.log(new Date().toISOString(), 'estado', store.getState())
})

process.on('SIGUSR2', () => store.dispatch({ type: 'incrementar' }))

Este reparto explica una asimetría que confunde a mucha gente: el paquete de integración de React es más grande y más complejo que el propio Redux. No es que Redux delegue trabajo en él; es que traducir una suscripción imperativa al modelo de render de React es un problema genuinamente difícil, mientras que el patrón que hay detrás del store es casi trivial. Cuando en las próximas lecciones veamos NgRx, Pinia o Nanostores, lo que cambiará entre ellos no será el flujo unidireccional —ese será siempre el mismo— sino precisamente esta capa: cómo cada framework se entera de que el estado cambió.

Establecer esa frontera con nitidez tiene un efecto inmediato sobre cómo organizas el código. Si el núcleo es agnóstico, no hay razón para que tus reducers, tus acciones y tus selectores importen nada de React, y mantenerlos limpios de esa dependencia es una regla barata con un rendimiento alto: puedes probarlos en Node sin montar un renderizador, reutilizarlos si parte de la lógica se mueve a un worker o al servidor, y sobre todo sabes en todo momento qué parte de tu aplicación se juega en una migración de framework y cuál no. La mayoría de las bases de código mezclan ambas capas sin necesidad, y el precio no se paga hasta el día en que hay que mudarse.