redux-thunk: despachar funciones para la asincronía simple

La primera necesidad que revienta el modelo de Redux es la asincronía. El dispatch solo acepta objetos planos y el reducer es rigurosamente síncrono, así que ¿cómo despachas el resultado de un fetch que todavía no ha llegado? redux-thunk responde con una jugada minúscula y elegante: permite despachar también funciones. Una función así —un thunk— es una computación aplazada que, cuando el middleware la intercepta, se ejecuta recibiendo dispatch y getState. De pronto tienes un lugar donde esperar promesas, leer el estado actual y despachar varias acciones en secuencia —cargando, éxito, error— sin ensuciar ni el reducer ni el componente. Es el enfoque asíncrono por defecto de Redux Toolkit, y su virtud es también su frontera: es imperativo, directo y sin ceremonia, perfecto mientras el flujo sea un recado con principio y fin.

El thunk: una computación diferida

La palabra viene de la implementación de Algol 60: un thunk era el fragmento de código que el compilador generaba para calcular un argumento pasado por nombre, aplazado hasta que de verdad se usara. La idea sobrevivió en programación funcional como una función sin argumentos —o casi— que envuelve un cálculo para ejecutarlo más tarde, como () => 40 + 2 en lugar del 42 ya cocinado. Redux toma prestado exactamente ese gesto: en vez de despachar el valor —un objeto de acción ya formado—, despachas la receta que producirá valores luego —una función—. El aplazamiento no es un detalle, es el mecanismo entero: ese hueco temporal es donde cabe la espera de una promesa.

El middleware que lo hace posible es célebre por su tamaño; cabe casi en un tuit y no esconde nada.

import type { Dispatch } from "@reduxjs/toolkit";

// El middleware thunk, entero: si la accion es una funcion, la ejecuta.
const thunk =
  ({ dispatch, getState }: { dispatch: Dispatch; getState: () => unknown }) =>
  (next: Dispatch) =>
  (action: unknown) =>
    typeof action === "function"
      ? action(dispatch, getState) // es un thunk: lo corremos y devolvemos su retorno
      : next(action); // es un objeto plano: sigue por la cadena

Toda la funcionalidad está en esa bifurcación: si lo que llega es una función, el thunk la llama pasándole dispatch y getState y devuelve lo que la función devuelva —por eso puedes hacer await dispatch(unThunk())—; si es un objeto plano, lo deja continuar. No hay más. Lo que el usuario percibe como “Redux ahora es asíncrono” no es un motor nuevo, es un dispatch sobrecargado para aceptar funciones además de objetos. Esa economía —añadir una capacidad enorme con una rama de nueve líneas— es la razón por la que el thunk fue durante años el patrón asíncrono canónico y sigue siendo el punto de partida.

Despachar lógica asíncrona a mano

Escrito a mano, un thunk es una función que retorna otra función; la interior recibe dispatch y getState y orquesta el flujo. El patrón universal es el trío: despacha una acción de cargando, espera la promesa, y despacha éxito o error según el desenlace. Con getState a mano puedes además cortar el efecto antes de empezar —no vuelvas a pedir un usuario que ya tienes—, y devolver la promesa deja que el componente haga await si necesita encadenar.

import type { ThunkAction, UnknownAction } from "@reduxjs/toolkit";
import type { RootState } from "./store";

export const cargarUsuario =
  (id: string): ThunkAction<Promise<void>, RootState, unknown, UnknownAction> =>
  async (dispatch, getState) => {
    if (getState().usuario.datos?.id === id) return; // ya lo tenemos, no repitas
    dispatch({ type: "usuario/cargando" });
    try {
      const r = await fetch(`/api/usuarios/${id}`);
      dispatch({ type: "usuario/exito", payload: await r.json() });
    } catch (e) {
      dispatch({ type: "usuario/error", payload: String(e) });
    }
  };

flowchart TD
A[dispatch del thunk] --> P[se despacha cargando]
P --> Q[corre la funcion async]
Q -->|resuelve| F[se despacha exito]
Q -->|lanza o rechaza| R[se despacha error]
F --> S[reducer pasa a listo]
R --> T[reducer pasa a error]
style P fill:#f9e2af,color:#11111b
style F fill:#a6e3a1,color:#11111b
style R fill:#f38ba8,color:#11111b

createAsyncThunk: el thunk que RTK genera

Escribir ese trío a mano una y otra vez es repetitivo y propenso a olvidos, así que Redux Toolkit lo codificó. createAsyncThunk recibe un prefijo de tipo y un payload creator asíncrono, y a cambio genera tres creadores de acción —.pending, .fulfilled, .rejected— y los despacha automáticamente alrededor de tu promesa. Tú solo escribes la parte interesante —la petición— y manejas los tres desenlaces en extraReducers. El segundo argumento del creador, el thunkAPI, expone dispatch, getState, un signal de tipo AbortSignal para cancelar, rejectWithValue para devolver errores tipados y condition para abortar antes de empezar.

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

export const cargarUsuario = createAsyncThunk(
  "usuario/cargar",
  async (id: string, thunkAPI) => {
    const r = await fetch(`/api/usuarios/${id}`, { signal: thunkAPI.signal });
    if (!r.ok) return thunkAPI.rejectWithValue("no encontrado");
    return (await r.json()) as { nombre: string };
  },
);

const slice = createSlice({
  name: "usuario",
  initialState: { datos: null, estado: "inactivo" } as {
    datos: { nombre: string } | null;
    estado: "inactivo" | "cargando" | "listo" | "error";
  },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(cargarUsuario.pending, (s) => void (s.estado = "cargando"))
      .addCase(cargarUsuario.fulfilled, (s, a) => {
        s.estado = "listo";
        s.datos = a.payload;
      })
      .addCase(cargarUsuario.rejected, (s) => void (s.estado = "error"));
  },
});

Dos matices sobre la cancelación evitan falsas expectativas. thunkAPI.signal cancela la petición —el fetch aborta— pero no detiene el JavaScript ya en marcha: si el payload creator hace tres cosas seguidas, abortar no rebobina las dos primeras. La cancelación de un thunk es superficial, no cooperativa como la de un generador que se pausa entre yield. Y thunkAPI.condition deja abortar antes de empezar: devuelve false y el thunk ni siquiera despacha pending, ideal para deduplicar cargas ya en vuelo. Entre signal y condition cubres el “no empieces si sobra” y el “corta la petición que ya no interesa”, pero ninguno te da el take-latest fino que sí regalan la saga y el listener de las próximas lecciones.