El listener middleware de RTK: la alternativa moderna a saga

El listener middleware de RTK hace una apuesta afilada: casi todo lo que la gente pedía a saga —reaccionar a una acción, esperar a otra, cancelar la ejecución anterior, agrupar las ráfagas— no necesitaba generadores ni efectos-como-dato, sino solo un buen vocabulario de suscripción y cancelación expresado en el async/await que ya dominas. createListenerMiddleware te deja registrar oyentes con la forma “cuando ocurra esta acción, corre este efecto”, y el listenerApi que recibe cada efecto trae las piezas que hacían potente a saga —take, condition, fork, cancelación cooperativa— sin un solo function*. Es la alternativa moderna: la coreografía de saga para el ochenta por ciento de los casos, escrita como promesas normales. Y reubica la lógica reactiva en su hogar correcto —ni en los componentes, ni en el reducer— como un registro declarativo de reacciones al flujo de acciones.

Suscribirse al flujo de acciones

Creas el middleware con createListenerMiddleware, lo cableas en configureStore con prepend —para que vea las acciones antes que las guardas por defecto— y registras oyentes con startListening. Cada oyente declara cuándo dispara y qué hace. El cuándo admite tres formas de precisión creciente: actionCreator para un tipo exacto, matcher para un grupo —los isAnyOf o los matchers de createAsyncThunk—, y predicate para una condición arbitraria sobre la acción y el estado, que es lo que te deja disparar cuando un valor derivado cruza un umbral, no solo cuando llega un tipo.

import { createListenerMiddleware, addListener } from "@reduxjs/toolkit";
import type { RootState, AppDispatch } from "./store";
import { login } from "./sesionSlice";
import { registrarAnalitica } from "./analitica";

export const listenerMiddleware = createListenerMiddleware();

// startListening tipado: conoce RootState y AppDispatch en cada effect
const startAppListening = listenerMiddleware.startListening.withTypes<
  RootState,
  AppDispatch
>();

startAppListening({
  actionCreator: login,
  effect: async (action, api) => {
    // corre despues de que el reducer ya aplico el login
    api.dispatch(registrarAnalitica("login", action.payload.id));
  },
});

Esperar el futuro sin generadores

Aquí es donde el listener alcanza a saga. El listenerApi trae condition, que pausa el efecto hasta que se cumple un predicado sobre una acción o el estado futuros; take, que espera una acción concreta y devuelve la tupla [accion, estado]; delay, para temporizar; y cancelActiveListeners, que mata las ejecuciones anteriores de este mismo oyente. Con esas piezas, el debounce y el “quédate con la última” —que costaban contabilidad manual en thunk y una palabra en saga— se escriben en async/await directo.

import { buscar, consultar, mostrar } from "./busquedaSlice";

startAppListening({
  actionCreator: buscar,
  effect: async (action, api) => {
    api.cancelActiveListeners(); // mata la ejecucion previa: esto es take-latest
    await api.delay(300); // debounce; si llega otra busqueda antes, esta se cancela aqui
    const resultados = await api.dispatch(consultar(action.payload)).unwrap();
    api.dispatch(mostrar(resultados));
  },
});

startAppListening({
  actionCreator: abrirAsistente,
  effect: async (action, api) => {
    // take: pausa hasta que llegue aceptar o cancelar; el mismo handshake de saga
    const [confirmado] = await api.take(
      (a) => aceptar.match(a) || cancelar.match(a),
    );
    if (aceptar.match(confirmado)) await api.dispatch(guardar()).unwrap();
  },
});

Un detalle recurrente en esos efectos es unwrap. Cuando despachas un createAsyncThunk desde un listener, dispatch(thunk()) devuelve una promesa que siempre se resuelve —lleva dentro el resultado o el error como datos, nunca lanza—; encadenar .unwrap() la convierte en una promesa que resuelve con el valor o lanza el error, para que uses try/catch normal dentro del efecto. Así el listener orquesta thunks —espera a que uno acabe, decide según su resultado, dispara el siguiente— combinando lo mejor de ambos escalones: el thunk hace el recado, el listener coordina la conversación entre recados.

flowchart LR
D[accion despachada] --> R[reducer actualiza el estado]
D --> L[listener evalua predicados]
L -->|coincide| E[corre el effect async]
E -->|dispatch| D
E -.cancelActiveListeners.-> X[cancela ejecuciones previas]
style R fill:#a6e3a1,color:#11111b
style E fill:#89b4fa,color:#11111b
style X fill:#f38ba8,color:#11111b

La alternativa moderna a saga

El listener se sitúa exactamente entre el thunk y la saga. Sobre el thunk gana la suscripción: no es un efecto de un solo tiro que despachas una vez, sino un oyente permanente que reacciona a cada aparición de una acción, y transversal, porque una rebanada puede reaccionar a las acciones de otra sin acoplarse a ella. Sobre la saga gana la familiaridad: fork, take, cancelación y debounce sin generadores ni la indirección de efectos-como-dato, porque aquí sí ejecutas el efecto —es await fetch(...) de verdad—, no describes uno. Además es dinámico: puedes añadir y quitar oyentes en tiempo de ejecución con dispatch(addListener(...)) y la baja que retorna, lo que encaja con el code splitting.

Visto desde el nivel 3, el listener es el patrón Observer llevado a su conclusión natural: el flujo de acciones es el sujeto observable de toda la aplicación, y cada oyente es un observador que reacciona a él con lógica arbitraria y ciclo de vida propio. Donde RxJS te daría operadores sobre un stream —debounceTime, switchMap—, el listener te ofrece sus equivalentes imperativos —delay, cancelActiveListeners— sin obligarte a adoptar el álgebra entera de los observables. Es reactividad sobre el mismísimo stream que ya alimenta al reducer, sin una segunda fuente de verdad que mantener sincronizada: el mismo hecho que actualiza el estado dispara el efecto, y ambos leen de la única corriente de acciones.