Por qué Redux ganó sobre el Flux original

Cuando Dan Abramov y Andrew Clark presentaron Redux en 2015, no añadieron nada a Flux: le quitaron cosas. Donde Flux tenía muchos stores, Redux dejó uno; donde Flux tenía un dispatcher con mecanismos de ordenación, Redux dejó un método casi vacío; donde los stores de Flux mutaban objetos, Redux exigió funciones puras. El resultado fue una herramienta más pequeña que su antecesora y, precisamente por serlo, mucho más poderosa. Redux ganó la guerra de las implementaciones de Flux no por hacer más, sino por hacer menos con más disciplina, y la recompensa de esa disciplina fue un ecosistema de herramientas que ninguna alternativa flexible pudo igualar. Esta lección disecciona sus tres decisiones y extrae la moraleja.

Un solo store: el árbol único

La primera y más radical decisión de Redux fue tener un único store para toda la aplicación. Todo el estado vive en un solo objeto, un árbol, en lugar de repartirse entre muchos stores independientes como en Flux. Esto parece una limitación —¿no se vuelve inmanejable?— pero resuelve de un plumazo el problema más espinoso de Flux: las dependencias entre stores.

Recuerda el waitFor de la lección dos, con el que un store esperaba a que otro procesara la action antes de reaccionar. Ese mecanismo existía porque había varios stores y el orden entre ellos importaba. Con un solo store, no hay varios stores que ordenar, así que la pregunta “¿quién procesa primero?” simplemente desaparece. Redux no resolvió el problema de la ordenación: lo disolvió eliminando la condición que lo hacía posible.

Esa centralización es a la vez la mayor fuerza de Redux y la razón de que existan alternativas más ligeras. Un árbol único es un mirador perfecto —todo el estado en un punto, inspeccionable de golpe— pero también una aduana por la que ha de pasar hasta el cambio más trivial. Para una aplicación grande con estado muy interconectado la aduana compensa; para un contador local o un formulario aislado es burocracia, y ahí es donde en 2026 brillan Zustand o el propio useState. Redux acertó con la idea del árbol único, pero el ecosistema aprendió después que no todo estado merece vivir en él, y esa lección es la que reparte hoy el trabajo entre Redux y sus primos ligeros.

Adiós al dispatcher y al waitFor

En Flux, el dispatcher era una pieza propia, un singleton con lógica de registro y de espera. En Redux, el dispatcher se encoge hasta ser un método del store, dispatch, cuyo trabajo es tan simple que casi da vergüenza: toma la action, se la pasa al reducer junto al estado actual, guarda lo que el reducer devuelve y avisa a los suscriptores.

// el corazon de Redux cabe en unas lineas: dispatch es casi trivial
function createStore(reducer) {
  let estado = reducer(undefined, { type: "@@INIT" });
  const oyentes = [];

  return {
    getState: () => estado,
    dispatch(accion) {
      estado = reducer(estado, accion); // toda la logica esta en el reducer
      oyentes.forEach((oyente) => oyente());
      return accion;
    },
    subscribe(oyente) {
      oyentes.push(oyente);
      return () => oyentes.splice(oyentes.indexOf(oyente), 1);
    },
  };
}

No hay register, no hay tokens, no hay waitFor. Toda la lógica que en Flux se repartía entre el dispatcher y los stores se concentra ahora en una única función, el reducer, que recibe el estado entero y devuelve el estado entero. El dispatcher dejó de ser una pieza para volverse un detalle de una línea.

Merece la pena detenerse en lo que este colapso significa conceptualmente. En Flux, el dispatcher era el sujeto activo —repartía, coordinaba, esperaba—; en Redux, el verbo se traslada del dispatcher al reducer, y el dispatcher queda reducido a pura fontanería. La inteligencia deja de estar en cómo se reparten los hechos y pasa a estar en cómo se interpretan, que es exactamente donde debe vivir la lógica de una aplicación. Flux distribuía la responsabilidad entre dos piezas difusas; Redux la concentra en una sola, nítida y comprobable.

Reducers puros: el corazón heredado de Elm

Aquí está la joya que Redux tomó de la Elm Architecture. Un reducer es una función pura con la firma (estado, action) => nuevoEstado: recibe el estado actual y una action, y devuelve el estado nuevo, sin mutar el viejo y sin efectos secundarios. La misma entrada produce siempre la misma salida.

// un reducer puro: sin mutacion, sin efectos, sin sorpresas
function contador(estado = 0, accion) {
  switch (accion.type) {
    case "INCREMENTAR":
      return estado + 1;
    case "DECREMENTAR":
      return estado - 1;
    default:
      return estado; // ante lo desconocido, devuelve el estado intacto
  }
}

Como el estado global es un solo árbol, Redux lo compone a partir de reducers pequeños con combineReducers, cada uno dueño de una rama. La pureza es la regla inviolable: un reducer que llama a una API, que lee la hora, que muta su argumento o que genera un identificador aleatorio deja de ser puro y rompe todas las garantías. Los efectos viven fuera, en middleware.

import { combineReducers } from "redux";
// el arbol unico se ensambla desde reducers puros por rama
const reducerRaiz = combineReducers({ contador, tareas, sesion });

Esa composición es la contrapartida de haber renunciado a los múltiples stores: no pierdes la modularidad, la recuperas como funciones puras que se combinan en un árbol, en lugar de como objetos con estado que se coordinan a mano con waitFor. Y como el reducer es total —contesta a toda action, aunque sea devolviendo el estado intacto en el default—, nunca existe un hecho que deje el sistema en un limbo indefinido: cada action tiene una respuesta definida sobre cada rama del árbol, lo que elimina de raíz otra familia de estados imposibles.

Por qué ganó la pureza: el tooling

Las tres decisiones anteriores convergen en una sola recompensa, y es la que de verdad ganó la guerra. Como el estado es un único valor serializable y solo cambia por reducers puros aplicados a actions que son datos, todo el historial de la aplicación se vuelve inspeccionable y reproducible. Y sobre esa base, Redux construyó un tooling que dejó a la competencia sin argumentos.

Ninguna de estas capacidades era alcanzable con los stores mutables y llenos de efectos del Flux original. Redux no ganó por marketing ni por ergonomía —de hecho, su verbosidad era legendaria y motivó Redux Toolkit—; ganó porque la disciplina de la pureza desbloqueó herramientas que la flexibilidad jamás habría permitido.

Hubo además un efecto de red que amplificó todo lo anterior: cuanto más se usaba Redux, más middleware, más extensiones del DevTools y más patrones documentados aparecían, y cada adición hacía a Redux un poco más inevitable para el siguiente equipo que decidía. La pureza fue la semilla, pero el ecosistema que creció sobre ella —thunk y saga para los efectos, reselect para las derivaciones, y más tarde Redux Toolkit para domar la verbosidad— fue lo que convirtió a Redux en la respuesta por defecto durante casi una década.

import { createSlice } from "@reduxjs/toolkit";

const slice = createSlice({
  name: "contador",
  initialState: { valor: 0 },
  reducers: {
    // parece mutacion, pero Immer la vuelve inmutable por debajo
    incrementar: (estado) => { estado.valor += 1; },
  },
});