createSlice: reducers, acciones e Immer en un solo lugar

Si configureStore es el esqueleto de una app con Redux Toolkit, createSlice es el músculo: la unidad donde declaras, en un solo bloque legible, qué forma tiene una porción del estado y cómo puede cambiar. Su golpe de gracia es doble. Por un lado, colapsa las tres piezas que el Redux clásico obligaba a mantener sincronizadas —tipos de acción, action creators y reducer— en una única declaración de la que RTK deriva todo lo demás. Por otro, integra Immer, y con él una ilusión productiva: dentro de un reducer escribes lo que parece una mutación directa, estado.items.push(x), y obtienes una actualización perfectamente inmutable. Entender por qué esa ilusión es segura, y dónde deja de serlo, es lo que separa usar createSlice de dominarlo.

Un slice es acciones y reducer a la vez

createSlice recibe un objeto de configuración y devuelve otro con tres piezas clave: slice.reducer, la función pura que registras en el store; slice.actions, un objeto con un action creator por cada clave de reducers; y slice.caseReducers, útil para tests. Los tipos de acción se derivan solos: la clave incrementar bajo un slice llamado contador produce el tipo contador/incrementar, sin que escribas esa cadena. Cada reducer recibe el estado y la acción; si necesitas el payload tipado, anotas el segundo argumento como PayloadAction<T>.

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

interface Todo { id: string; texto: string; hecho: boolean }

const todosSlice = createSlice({
  name: "todos",
  initialState: [] as Todo[],
  reducers: {
    anadido: (estado, accion: PayloadAction<Todo>) => {
      estado.push(accion.payload); // parece mutacion; Immer la hace inmutable
    },
    alternado: (estado, accion: PayloadAction<string>) => {
      const t = estado.find((x) => x.id === accion.payload);
      if (t) t.hecho = !t.hecho;
    },
  },
});

export const { anadido, alternado } = todosSlice.actions;
export default todosSlice.reducer;

Immer: mutar el borrador, no el estado

La magia no es magia: es un proxy. Cuando despachas una acción, Immer no te entrega el estado real sino un borrador, un proxy que registra cada escritura que haces sobre él. Al terminar el reducer, Immer usa ese registro para producir un estado nuevo aplicando solo los cambios anotados y reutilizando por referencia todo lo que no tocaste. Eso es compartición estructural: si cambias un elemento de un array de mil, los otros novecientos noventa y nueve se comparten con el estado anterior, no se copian. Obtienes la ergonomía de la mutación y la semántica de la inmutabilidad a la vez, sin spread anidado y sin copias innecesarias.

flowchart LR
A[dispatch de una accion] --> B[Immer crea un borrador]
B --> C[el reducer muta el borrador]
C --> D[Immer calcula los parches]
D --> E[estado nuevo inmutable]
E --> F[lo no tocado se comparte por referencia]
style B fill:#fab387,color:#11111b
style E fill:#a6e3a1,color:#11111b
style F fill:#89b4fa,color:#11111b

La regla que nunca debes romper nace de cómo funciona ese proxy: dentro de un reducer, o mutas el borrador y no devuelves nada, o devuelves un estado nuevo sin tocar el borrador. Hacer las dos cosas a la vez confunde a Immer, que no sabe si respetar tus parches o tu valor devuelto, y lanza un error. Devolver estado nuevo es legítimo y a veces más claro —reiniciar a un valor inicial, por ejemplo—, pero mezclarlo con mutaciones no lo es.

reducers: {
  // BIEN: muta el borrador y no devuelve nada
  anadir: (estado, accion: PayloadAction<Todo>) => {
    estado.items.push(accion.payload);
  },
  // BIEN: devuelve estado nuevo sin tocar el borrador
  reiniciar: () => inicial,
  // MAL: mutar Y devolver a la vez rompe Immer
  // roto: (estado) => { estado.n += 1; return estado; },
}

La forma prepare, extraReducers y selectores

A veces el action creator debe hacer trabajo antes de construir el payload: generar un id, poner una marca de tiempo, normalizar argumentos. Para eso está la forma de objeto con reducer y prepare: prepare recibe los argumentos de quien despacha y devuelve el objeto de acción, mientras reducer recibe ya el payload preparado. Y cuando un slice debe reaccionar a acciones que no son suyas —las de otro slice o los estados de un createAsyncThunk—, se usa extraReducers con el builder y su método addCase.

import { createSlice, nanoid, type PayloadAction } from "@reduxjs/toolkit";

const todos = createSlice({
  name: "todos",
  initialState: { lista: [] as Todo[] },
  reducers: {
    anadido: {
      reducer: (estado, accion: PayloadAction<Todo>) => {
        estado.lista.push(accion.payload);
      },
      prepare: (texto: string) => ({
        payload: { id: nanoid(), texto, hecho: false },
      }),
    },
  },
  // responde a acciones externas, como un thunk de otro modulo
  extraReducers: (builder) => {
    builder.addCase(sincronizar.fulfilled, (estado, accion) => {
      estado.lista = accion.payload;
    });
  },
  // selectores colocados junto al slice, con el estado ya recortado a esta porcion
  selectors: {
    seleccionarPendientes: (estado) => estado.lista.filter((t) => !t.hecho),
  },
});

export const { anadido } = todos.actions;
export const { seleccionarPendientes } = todos.selectors;