RootState y AppDispatch: inferir los tipos del store

Hay un momento en toda app con Redux y TypeScript en que alguien escribe una interfaz llamada RootState y la rellena a mano con los nombres de los slices. Funciona el primer día y empieza a mentir el segundo. La tesis de este nivel entero, y la de esta lección en particular, es que esa interfaz no debería existir: el store construido con configureStore ya contiene la forma exacta del estado y la firma exacta de dispatch, porque ambas se derivan mecánicamente de los reducers y del middleware que le pasaste. Volver a escribirlas es duplicar una verdad, y toda verdad duplicada acaba convertida en dos verdades que discrepan. La alternativa cabe en dos líneas: dos alias de tipo extraídos del store con typeof, que se recalculan solos cada vez que el estado cambia de forma y que se convierten en la fuente única de la que bebe el resto del proyecto.

Dos verdades que el store ya conoce

Cuando llamas a configureStore con un mapa de reducers, Redux Toolkit los combina en un reducer raíz cuyo tipo de retorno es, literalmente, la forma del estado: un objeto con una clave por slice y, en cada clave, el tipo de estado que ese slice declara. Ese tipo no es una aproximación ni una convención, es el resultado del cálculo que hace el compilador al ver tus reducers. Y como store.getState devuelve exactamente eso, el tipo del estado global está a un ReturnType de distancia. La segunda verdad es más sutil: store.dispatch tampoco es una función genérica cualquiera. El dispatch base solo acepta objetos de acción planos, pero cada middleware que amplía lo despachable amplía también su firma, de modo que el dispatch de un store con thunk acepta además funciones y devuelve lo que esas funciones devuelvan. Esa firma ampliada solo existe en el store real; ningún tipo importado de redux la reproduce.

De ahí nacen las tres desincronizaciones clásicas del RootState escrito a mano. La primera es por omisión: añades un slice al store y olvidas añadirlo a la interfaz, así que un selector legítimo sobre la rama nueva no compila y alguien lo arregla con una aserción. La segunda es por deriva: cambias la forma interna de un slice y la interfaz sigue describiendo la anterior, de modo que todos los selectores compilan contra una mentira y fallan solo en tiempo de ejecución, que es el peor momento posible. La tercera es por empobrecimiento: tipas dispatch como el Dispatch de redux y pierdes las sobrecargas del thunk, así que despachar un thunk deja de compilar y el equipo aprende a escribir as any en cada llamada, abriendo un agujero que la lección quinta de este nivel estudia en detalle.

import { configureStore } from "@reduxjs/toolkit";
import todos from "../features/todos/todosSlice";
import filtros from "../features/filtros/filtrosSlice";

export const store = configureStore({
  reducer: { todos, filtros },
});

// los tres alias de los que vivira todo el proyecto
export type AppStore = typeof store;
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Inferir es dejar que el compilador copie por ti

El flujo de la inferencia va siempre en la misma dirección: de los reducers al store, del store a los alias, y de los alias a los selectores y los hooks. Nada apunta hacia atrás, y ese detalle es lo que hace que el esquema no pueda mentir. Si mañana renombras la clave filtros a filtrado, RootState cambia solo y cada selector que siga leyendo la clave vieja deja de compilar en el acto. Ese error no es una molestia: es exactamente el trabajo que le encargaste al sistema de tipos, señalar todos los puntos afectados por un cambio de forma antes de que alguien despliegue.

flowchart TD
A[reducers que pasas a configureStore] --> B[reducer raiz combinado]
B --> C[el store real]
C --> D[typeof store.getState]
C --> E[typeof store.dispatch]
D --> F[RootState]
E --> G[AppDispatch]
F --> H[selectores y hooks tipados]
G --> H
style C fill:#fab387,color:#11111b
style F fill:#a6e3a1,color:#11111b
style G fill:#89b4fa,color:#11111b

El primer consumidor de RootState son los selectores, y ahí el patrón se aprecia entero. Un selector se declara como una función cuyo parámetro se anota con el alias, y su retorno no se anota nunca porque se deduce del cuerpo. Esa asimetría es deliberada: la entrada es un contrato con el store y por eso se declara; la salida es una consecuencia del cálculo y por eso se infiere. Escribir el tipo de retorno a mano reintroduce, a escala pequeña, exactamente el problema que este nivel combate, porque crea una segunda afirmación que hay que mantener sincronizada con el cuerpo de la función.

import type { RootState } from "../../app/store";

// el parametro se declara; el retorno se deduce del cuerpo
export const seleccionarPendientes = (estado: RootState) =>
  estado.todos.lista.filter((t) => !t.hecho);

export const seleccionarTotal = (estado: RootState) => estado.todos.lista.length;

// si el slice cambia de forma, estas dos lineas dejan de compilar a la vez

Conviene detenerse en AppDispatch porque es donde más gente se equivoca. Su tipo real no es una función simple sino una intersección: la firma que acepta acciones planas más la firma que los middlewares añadieron, entre ellas la del thunk, que acepta una función y devuelve su resultado con el tipo correcto. Gracias a eso, despachar un thunk creado con createAsyncThunk no solo compila, sino que devuelve un objeto con unwrap cuyo tipo de retorno es el payload de fulfilled. Si en su lugar declaras el tipo como Dispatch, esa información desaparece y con ella la ergonomía entera de la asincronía tipada, tema de la cuarta lección de este nivel.

El patrón setupStore y la frontera de los tipos

Un slice necesita a veces referirse a RootState, por ejemplo para escribir un selector que cruza ramas o para tipar getState dentro de un thunk. Pero RootState vive en el módulo del store, y el módulo del store importa el reducer del slice: importar en la otra dirección cierra un ciclo. La solución tiene dos capas. La primera es usar siempre import type para traer los alias, porque una importación de solo tipos se borra en la compilación y el ciclo nunca llega a existir en tiempo de ejecución. La segunda, más limpia, es calcular la forma del estado desde el reducer raíz y no desde el store, con lo que el tipo deja de depender del módulo que crea la instancia.

Ese mismo movimiento resuelve otro problema, el de los tests. Compartir una única instancia de store entre pruebas contamina unas con otras, así que lo idiomático es una fábrica que construya un store nuevo por test, opcionalmente con estado precargado. Si los alias se derivan de la fábrica, la app y las pruebas comparten exactamente los mismos tipos sin escribirlos dos veces.

import { combineReducers, configureStore } from "@reduxjs/toolkit";
import todos from "../features/todos/todosSlice";
import filtros from "../features/filtros/filtrosSlice";

const rootReducer = combineReducers({ todos, filtros });

// la forma del estado depende del reducer, no de la instancia del store
export type RootState = ReturnType<typeof rootReducer>;

export function setupStore(preloadedState?: Partial<RootState>) {
  return configureStore({ reducer: rootReducer, preloadedState });
}

export type AppStore = ReturnType<typeof setupStore>;
export type AppDispatch = AppStore["dispatch"];

Merece la pena señalar qué cambia y qué no entre las dos versiones del store. La forma del estado pasa a depender del reducer raíz, que es un valor puro y sin instancias, así que puede importarse desde cualquier parte sin arrastrar la creación del store. AppDispatch, en cambio, sigue dependiendo del store porque las sobrecargas de los middlewares solo existen en la instancia construida, y por eso se deriva del tipo devuelto por la fábrica. Esa separación entre lo que depende de la configuración y lo que depende de la instancia es la que permite que un mismo proyecto tenga varios stores, uno por prueba, sin duplicar un solo tipo.

Queda un cuarto alias que muchos proyectos exportan junto a los otros tres, útil solo si escribes thunks a mano en lugar de con createAsyncThunk. Un thunk artesanal es una función que recibe dispatch y getState, y para tiparla hace falta decir de qué estado habla y qué devuelve. El tipo utilitario de Redux lo permite, y envolverlo con los alias del proyecto evita repetir cuatro parámetros en cada thunk.

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

export type AppThunk<R = void> = ThunkAction<R, RootState, unknown, UnknownAction>;

// uso: dispatch y getState llegan tipados sin anotar nada mas
export const alternarSiHayPocos = (): AppThunk => (dispatch, getState) => {
  if (getState().todos.lista.length < 5) dispatch(limpiado());
};