Las piezas de Flux: action, dispatcher, store, view

Flux no es una librería con muchas funciones; es un reparto de responsabilidades con cuatro papeles. Lo notable de ese reparto no es lo que cada pieza puede hacer, sino lo que se le prohíbe hacer. La action no tiene lógica, el dispatcher no tiene estado, el store no tiene setters públicos y la view no muta nada directamente. Cada pieza es una restricción disfrazada de componente, y al encajarlas obtienes un sistema donde el estado solo puede cambiar por un camino. Vamos a diseccionar las cuatro, entender el rol exacto de cada una y ver por qué sus límites son su virtud.

La action: un hecho con nombre

Una action es un objeto plano que describe algo que ocurrió. No es una orden imperativa —no dice “cambia el contador”— sino un hecho en pasado —“el usuario pulsó incrementar”—. Esa distinción es semántica pero decisiva: quien crea la action no sabe ni le importa quién reaccionará a ella ni cómo. La action solo declara qué pasó, y deja la interpretación a los stores.

// una action es dato plano: un tipo y una carga util
const accionAnadirTarea = {
  type: "ANADIR_TAREA",
  texto: "estudiar flux",
};

// las "action creators" fabrican y despachan la action
function anadirTarea(texto) {
  dispatcher.dispatch({ type: "ANADIR_TAREA", texto });
}

Que la action sea dato plano, y no una llamada a función, tiene una consecuencia enorme que explotaremos en las próximas lecciones: se puede registrar en un log, serializar, enviar por la red, guardar y reproducir. Un hecho es inspeccionable; una orden imperativa se ejecuta y se pierde. El campo type suele ser una cadena constante que actúa como identificador del hecho.

El dispatcher: el centro que reparte

El dispatcher es la pieza más singular de Flux y la que sus herederos abandonarían. Es un singleton —hay exactamente uno en toda la aplicación— cuyo único trabajo es recibir cada action y reenviarla a todos los stores registrados, en secuencia. No guarda estado ni contiene lógica de negocio; es un repartidor de correo que entrega cada carta a todos los buzones.

import { Dispatcher } from "flux";
export const dispatcher = new Dispatcher();

// cada store se registra y recibe TODAS las actions
const tokenTareas = dispatcher.register((accion) => {
  switch (accion.type) {
    case "ANADIR_TAREA":
      storeTareas.anadir(accion.texto);
      storeTareas.emitirCambio();
      break;
  }
});

Su valor está en centralizar: como toda action pasa por un único punto, ese punto es también el único lugar donde observar todo lo que ocurre en la aplicación. Cuando un store necesita que otro procese la action antes que él —porque depende de su resultado—, el dispatcher ofrece waitFor, que pausa un store hasta que los tokens indicados hayan terminado.

dispatcher.register((accion) => {
  if (accion.type === "ANADIR_TAREA") {
    // no proceses hasta que el store de tareas haya actualizado
    dispatcher.waitFor([tokenTareas]);
    storeResumen.recalcular();
  }
});

El store: estado y lógica de un dominio

El store guarda el estado de un dominio —las tareas, la sesión, las notificaciones— y toda la lógica que lo transforma. Es la única pieza que contiene datos que sobreviven entre acciones. Su rasgo definitorio, y el más importante de todo Flux, es que no expone setters: nadie puede escribir store.tareas = [] desde fuera. El store solo cambia como reacción a una action recibida a través del dispatcher, y cuando cambia, emite un evento para que las vistas se enteren.

import { EventEmitter } from "events";

class StoreTareas extends EventEmitter {
  #tareas = [];

  anadir(texto) {
    this.#tareas.push({ texto, hecha: false });
  }

  obtenerTodas() {
    return this.#tareas; // solo lectura hacia fuera
  }

  emitirCambio() {
    this.emit("cambio");
  }
  suscribir(cb) {
    this.on("cambio", cb);
  }
}

La ausencia de setters no es un descuido: es la restricción central. Al cerrar la puerta de la escritura directa, el store obliga a que todo cambio entre por la única puerta legítima —una action a través del dispatcher—. Ese es el mecanismo que rompe la red bidireccional de la lección anterior.

La view: observa y se redibuja

La view es la capa de React. Se suscribe a los stores de los que depende, lee su estado y se redibuja cuando reciben un evento de cambio. En el Flux original existía un patrón llamado controller-view: un componente cercano a la raíz que se suscribe a los stores y pasa los datos hacia abajo a componentes puros de presentación.

class ListaTareas extends React.Component {
  state = { tareas: storeTareas.obtenerTodas() };

  componentDidMount() {
    storeTareas.suscribir(() =>
      this.setState({ tareas: storeTareas.obtenerTodas() })
    );
  }

  // al interactuar, la vista NO muta el store: despacha una action
  alEnviar = (texto) => anadirTarea(texto);
}

El punto crucial está en alEnviar: cuando el usuario actúa, la vista no toca el store ni cambia nada directamente. Emite una nueva action y deja que el ciclo la lleve de vuelta al dispatcher. La vista es una función de los stores en una dirección, y una fábrica de actions en la otra —nunca un mutador.

Antes de cerrar, un mapa de las cuatro piezas y su única responsabilidad, para fijarlas juntas y no confundir sus fronteras: