configureStore: el store con buenos defaults

El createStore del Redux clásico era honesto pero desnudo: te daba un store vacío y dejaba en tus manos ensamblar todo lo demás, applyMiddleware para el thunk, composeWithDevTools para la inspección, combineReducers para juntar slices, y acertar el orden de esa composición o sufrir bugs sutiles. configureStore invierte la carga de la prueba: en vez de partir de la nada y añadir, parte de una configuración experta y te deja quitar o ajustar. Con una llamada obtienes un store que combina tus reducers, ejecuta thunks, se conecta a las DevTools y monta en desarrollo un cuerpo de guardianes que atrapan los errores más comunes de Redux antes de que lleguen a producción. No es azúcar: es una década de experiencia depurando Redux, condensada en los valores por defecto.

Un store bien equipado sin cablearlo

configureStore acepta un mapa de reducers y hace por debajo el combineReducers que antes escribías tú: cada clave se convierte en una rama del árbol de estado. Encima, y sin que digas nada, instala redux-thunk para que puedas despachar funciones y thunks, conecta la extensión Redux DevTools con su time-travel, y en modo desarrollo activa las comprobaciones de inmutabilidad y serializabilidad. La misma llamada que monta el store te devuelve el material para inferir sus tipos, que es lo que hace tipable el resto de la app.

import { configureStore } from "@reduxjs/toolkit";
import contador from "./contadorSlice";
import sesion from "./sesionSlice";

export const store = configureStore({
  reducer: { contador, sesion },
  // devTools, thunk y comprobaciones de desarrollo ya vienen puestos
});

// tipos inferidos del store real: nunca se desincronizan del estado
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Con esos dos tipos, los hooks de React-Redux 9 se tipan una vez y para siempre con withTypes, y a partir de ahí useAppSelector conoce la forma del estado y useAppDispatch acepta thunks sin quejarse.

import { useDispatch, useSelector } from "react-redux";
import type { RootState, AppDispatch } from "./store";

export const useAppDispatch = useDispatch.withTypes<AppDispatch>();
export const useAppSelector = useSelector.withTypes<RootState>();

Lo que ya no cableas

El contraste con el createStore clásico deja ver cuánto andamiaje desaparece. Antes ensamblabas a mano el reducer combinado, el middleware y la conexión a DevTools, y un orden equivocado o un compose mal escrito te costaba una tarde de depuración:

// Redux clasico: cableado manual y fragil, esto es lo que ya NO escribes
import { createStore, applyMiddleware, combineReducers, compose } from "redux";
import thunk from "redux-thunk";

const raiz = combineReducers({ contador, sesion });
const componer =
  (globalThis as any).__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ ?? compose;
const store = createStore(raiz, componer(applyMiddleware(thunk)));

Todo eso lo resuelve una sola llamada a configureStore, que además incorpora las comprobaciones de desarrollo que el montaje manual jamás traía. La diferencia no es solo teclear menos: es no poder equivocarte en el orden ni olvidar una pieza.

Los guardianes de desarrollo

Los defaults más valiosos no son comodidades sino alarmas. configureStore monta tres middlewares de comprobación que solo corren en desarrollo, porque su coste es real y en producción sobra. El de inmutabilidad congela el estado y avisa si algo lo muta fuera de un reducer de Immer. El de serializabilidad recorre acciones y estado buscando valores que Redux no debería contener —promesas, funciones, instancias de clase, Map, Set— porque romperían la persistencia, el time-travel y la reproducibilidad. El de action creators avisa si despachas un action creator sin llamarlo. Son opiniones convertidas en runtime: para RTK, mutar el estado y guardar valores no serializables no son estilos discutibles, son bugs.

Middleware y efectos reactivos

Cuando necesites tocar la cadena de middleware, configureStore te obliga a hacerlo bien: el campo middleware recibe una función que te entrega getDefaultMiddleware, y tú devuelves esa base ajustada. Así nunca borras por accidente el thunk ni las comprobaciones; los conservas y añades encima. El orden importa —lo que va delante ve la acción antes—, y por eso existen prepend y concat. El añadido más útil de RTK moderno es el listenerMiddleware: la respuesta oficial y ligera para efectos reactivos, que en la mayoría de los casos jubila a las sagas y a los observables. Escuchas una acción y disparas un efecto, con cancelación incluida.

import { configureStore, createListenerMiddleware } from "@reduxjs/toolkit";
import { login } from "./sesionSlice";
import { cargarPreferencias } from "./prefsThunks";

export const escucha = createListenerMiddleware();

escucha.startListening({
  actionCreator: login.fulfilled,
  effect: async (accion, api) => {
    api.cancelActiveListeners(); // estilo takeLatest: cancela ejecuciones previas
    await api.delay(300);
    api.dispatch(cargarPreferencias(accion.payload.id));
  },
});

export const store = configureStore({
  reducer: raiz,
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware({
      serializableCheck: {
        ignoredActions: ["socket/mensajeRecibido"],
        ignoredPaths: ["socket.conexion"],
      },
    }).prepend(escucha.middleware), // el listener ve las acciones primero
});

flowchart LR
A[dispatch de una accion] --> B[listenerMiddleware]
B --> C[thunk]
C --> D[comprobaciones de desarrollo]
D --> E[reducer raiz]
E --> F[estado nuevo]
F --> G[Redux DevTools]
style D fill:#f9e2af,color:#11111b
style E fill:#a6e3a1,color:#11111b
style G fill:#cba6f7,color:#11111b