El flujo unidireccional

Puedes conocer las cuatro piezas de Flux al dedillo y aun así no haber entendido Flux, porque Flux no está en las piezas sino en cómo se conectan. La aportación no es tener actions, un dispatcher, stores y vistas; es que la información entre ellos fluye en una única dirección y jamás en la contraria. Un store nunca escribe en una view saltándose el ciclo; una view nunca muta un store. Todo cambio recorre el mismo circuito, siempre en el mismo sentido, y hasta la acción del usuario, que parece un retorno, es en realidad el inicio de una vuelta nueva. Esa geometría de sentido único es la que convierte un sistema impredecible en uno que se puede razonar.

El ciclo cerrado de un solo sentido

En el MVC de la primera lección, los datos iban y venían por cada canal. En Flux hay un solo circuito y una sola dirección. Una action entra en el dispatcher; el dispatcher la reparte a los stores; los stores actualizan su estado y avisan; las views leen el nuevo estado y se redibujan. Fin del recorrido. Cuando el usuario interactúa con una view, esa view no vuelve hacia atrás por el circuito: fabrica una action nueva y la mete de nuevo por el principio.

flowchart LR
A[action] --> D[dispatcher]
D --> S[store]
S --> V[view]
V -->|la interaccion crea una action nueva| A
style A fill:#89b4fa,color:#11111b
style D fill:#f9e2af,color:#11111b
style S fill:#a6e3a1,color:#11111b
style V fill:#cba6f7,color:#11111b

Compara este diagrama con el ovillo de flechas de doble punta de la lección uno. Aquí no hay una sola flecha que apunte hacia atrás. El circuito es un bucle, sí, pero un bucle recorrido siempre en el mismo sentido: cada vuelta empieza en una action y termina en una view que, si el usuario actúa, dará pie a otra action —otra vuelta— pero nunca a un flujo en reversa dentro de la misma vuelta.

La vista nunca escribe: despacha

El punto donde el MVC se rompía era el retorno: la vista escribía en el modelo, el modelo en otras vistas, y el sentido de la información se perdía. Flux cierra esa fuga con una regla sin excepciones: la view no muta nada, solo despacha. Todo lo que el usuario provoca se traduce en una action, y esa action recorre el circuito completo antes de que la pantalla cambie.

// PROHIBIDO en Flux: la vista escribe directamente en el store
function alPulsar() {
  storeTareas.tareas.push(nueva); // rompe el sentido unico
}

// CORRECTO: la vista solo fabrica un hecho y lo despacha
function alPulsar() {
  dispatcher.dispatch({ type: "ANADIR_TAREA", texto: nueva });
  // el cambio volvera por el circuito: dispatcher, store, y de vuelta a la view
}

Parece un rodeo —¿por qué no tocar el store y ya está?— pero ese rodeo es precisamente lo que se compra. Al obligar a que todo pase por el mismo canal en el mismo orden, ningún cambio puede colarse por un atajo lateral. El coste es una pizca de ceremonia; el beneficio es que no existe ni un solo camino por el que el estado cambie sin dejar rastro.

Por qué la dirección única trae predecibilidad

Aquí está el argumento central del nivel, y conviene formularlo con precisión. La predecibilidad no es una cualidad que se añade; es una que se consigue quitando cosas. Un sistema es predecible cuando no tiene comportamientos sorpresa, y un comportamiento sorpresa es siempre un camino de causalidad que no esperabas. El MVC era impredecible porque admitía demasiados caminos; Flux es predecible porque admite uno solo.

Piénsalo como una pregunta de depuración. En el MVC, “¿por qué cambió este valor?” era una investigación: había que recorrer hacia atrás todas las flechas entrantes, y como formaban ciclos, la investigación podía no terminar. En Flux, la misma pregunta es una lectura: el valor cambió porque un store reaccionó a una action, y para saber cuál miras el log. Se pasa de un problema de búsqueda en un grafo a una consulta en una lista ordenada. Esa rebaja de complejidad no es incremental; cambia la categoría del problema.

Hay una consecuencia más profunda: el determinismo. Si el estado solo cambia por actions, y las actions son datos, entonces la misma secuencia de actions aplicada al mismo estado inicial produce siempre el mismo estado final. El sistema se vuelve una función pura del historial de hechos. Esa propiedad —que en el MVC era imposible porque el orden de propagación era emergente— es la que abre la puerta a reproducir sesiones, viajar en el tiempo entre estados y probar la lógica sin tocar la pantalla.