Los tres principios

Redux no es una librería que aprendes: es una disciplina que aceptas. Donde el nivel anterior te dio la forma del flujo unidireccional —acción, dispatcher, store, vista—, Redux la reduce a su mínimo matemático y la condensa en tres reglas. La intuición que lo gobierna todo es contraintuitiva: la previsibilidad no es una función que se añade, sino lo que queda cuando restas las maneras en que el estado podía cambiar de forma impredecible. Cada uno de los tres principios elimina un grado de libertad, y de esa sustracción deliberada nace un sistema donde, dado el estado y una acción, el siguiente estado no es una opinión sino un teorema.

De Flux a tres reglas

Flux te dio la dirección del flujo, pero dejó abiertas mil implementaciones: cuántos stores, cómo mutan por dentro, quién orquesta el dispatcher. Redux —Dan Abramov y Andrew Clark, 2015— colapsó esa ambigüedad tomando prestada de Elm una idea radical: un solo store y una función pura que calcula el siguiente estado. Desaparecen los múltiples stores con métodos que mutan por dentro y aparece un único árbol de estado transformado por reducers. El genio de Redux fue restar, no sumar: menos piezas móviles, menos lugares donde el estado puede cambiar, más garantías sobre lo que ocurre.

Conviene enumerar lo que Redux suprimió respecto a Flux, porque cada supresión fue una decisión. Desaparecen los múltiples stores y, con ellos, la coreografía de un store esperando a otro con waitFor; queda uno solo. Desaparece el dispatcher como objeto aparte en el que los stores se registran: el propio store expone dispatch y no hace falta más. Y desaparecen, sobre todo, los métodos que mutaban el estado dentro de cada store, sustituidos por una función que ni siquiera puede ver el estado salvo el que recibe por parámetro. Restar esas tres piezas es justo lo que hizo posible algo impensable en Flux: reconstruir cualquier estado pasado a partir del historial de acciones.

El resultado es un ciclo cerrado y de un solo sentido. La vista despacha una acción que describe qué pasó; el reducer, viendo el estado anterior y la acción, calcula el siguiente; el store guarda ese nuevo estado y avisa a la vista, que se recalcula. Nada se salta el círculo, y por eso cada cambio tiene una causa nombrada y rastreable.

flowchart LR
V[vista] -->|dispatch| A[accion describe que paso]
A --> R[reducer estado mas accion]
R --> S[store nuevo estado]
S -->|notifica y getState| V
style S fill:#cba6f7,color:#11111b
style A fill:#f9e2af,color:#11111b
style R fill:#89b4fa,color:#11111b
style V fill:#a6e3a1,color:#11111b

Ese ciclo tiene una propiedad que lo distingue de la reactividad automática de los signals del nivel 4: es explícito de principio a fin. No hay observación mágica de propiedades ni dependencias que se descubran solas; hay un gesto nombrado —el dispatch— que entra por un único sitio y una propagación que puedes seguir con el dedo. Redux cambia la comodidad de lo implícito por la trazabilidad de lo explícito, y ese trueque es la tesis que justifica toda su ceremonia.

Las tres reglas de un vistazo

Los principios no se entienden por separado: son un contrato de tres cláusulas donde cada una sostiene a las otras. Un store único solo es tratable si es de solo lectura, y el solo lectura solo es útil si el cambio se expresa como algo inspeccionable —una función pura de estado y acción—.

Una forma de fijarlos es verlos como tres cerrojos sobre la entropía. Sin el primero, el mismo hecho puede vivir en varios sitios y contradecirse. Sin el segundo, el estado puede cambiar desde cualquier parte y por cualquier vía, y averiguar quién lo tocó se vuelve imposible. Sin el tercero, el cambio puede depender de la hora, de la red o del azar, y deja de ser reproducible. Cada principio clausura una rendija por la que se colaba lo impredecible; juntos no dejan ninguna abierta, y esa clausura total es lo que la palabra previsibilidad significa aquí.

Uno y dos: un store de solo lectura

Los dos primeros principios son en realidad el corolario del nivel 1 llevado a su extremo. Si cada dato debe tener un dueño único, Redux propone un dueño único para todo el estado compartido: el store. Y si la duplicación era el bug más profundo, el “solo lectura” es la muralla que la impide, porque cierra todas las puertas de escritura salvo una. Leer siempre está permitido —getState devuelve el árbol completo—, pero cambiarlo tiene una sola vía sancionada: despachar una acción.

Que todo el estado comparta un solo objeto acarrea ventajas que no se notan hasta que faltan. Serializarlo es un JSON.stringify del árbol entero, lo que abarata el guardado en disco, el envío al servidor y la reconstrucción de una sesión. Escuchar cualquier cambio es un único punto de suscripción, no una maraña de oyentes repartidos. Y tomar una instantánea coherente del estado en un instante dado —para adjuntarla a un informe de error, pongamos— es leer una referencia, no recolectar fragmentos que podrían pertenecer a momentos distintos. La unicidad del store no es purismo minimalista: es lo que vuelve baratas operaciones que, con el estado fragmentado, serían costosas o imposibles.

import { createStore } from 'redux' // en 2026: configureStore de @reduxjs/toolkit

const store = createStore(reducer)

store.getState()                                    // leer: siempre permitido
store.dispatch({ type: 'contador/incrementado' })   // cambiar: unica via legal
// store.state = 99                                 // no existe: el estado no se asigna

Tres: los cambios son funciones puras

El tercer principio es el que da poder a los otros dos. Si el cambio se expresara como un método que muta el store por dentro, no ganarías nada; el secreto es que el cambio sea una función pura: recibe el estado anterior y la acción, y devuelve un estado nuevo sin tocar el viejo ni provocar efectos. Esa función es el reducer, y su firma —(estado, accion) => nuevoEstado— es toda la teoría de Redux comprimida en una línea.

El reducer no es un detalle de implementación entre muchos: es el único sitio donde el estado se transforma, y por eso concentrar ahí toda la lógica de cambio es lo que garantiza que un cambio nunca ocurra a tus espaldas. Todo lo que le pasa al estado, sin excepción, pasa por una de estas funciones, y esa exclusividad es lo que hace que el sistema entero quepa en la cabeza.

type Estado = { valor: number }
const inicial: Estado = { valor: 0 }

function reducer(estado = inicial, accion: { type: string }): Estado {
  switch (accion.type) {
    case 'contador/incrementado':
      return { valor: estado.valor + 1 } // objeto nuevo, jamas mutacion
    default:
      return estado                      // accion desconocida: sin cambios
  }
}

Que el reducer sea puro es lo que convierte al historial de acciones en algo reproducible: si el estado de hoy es acciones.reduce(reducer, inicial), entonces reproducirlo, rebobinarlo o saltar a cualquier punto del pasado es volver a plegar la misma lista. De ahí sale el time-travel de las DevTools, el testing trivial y la hidratación en servidor. La pureza no es purismo académico: es la moneda con la que compras reproducibilidad, y la desarrollaremos a fondo en la lección de reducers.

Esa tercera regla es también la que explica por qué Redux insiste tanto en la inmutabilidad. Si el reducer devolviera el mismo objeto mutado, el estado anterior y el nuevo serían el mismo en memoria y el historial se corrompería: no quedaría un antes al que regresar. Devolver siempre un objeto nuevo, dejando intacto el viejo, es lo que conserva la cadena de estados pasados sobre la que se levanta todo lo demás. Pureza e inmutabilidad no son dos exigencias distintas, sino la misma vista desde dos ángulos.