Cuándo Redux Toolkit sigue siendo la elección

La narrativa fácil dice que Redux murió y que en 2026 nadie debería empezar un proyecto con él. La narrativa fácil confunde dos cosas. El Redux artesanal de 2016 —con sus creadores de acciones escritos a mano, sus constantes de texto y su boilerplate ceremonioso— sí está muerto, y con razón. Pero Redux Toolkit, la forma oficial y opinada de escribir Redux, sigue siendo la elección correcta para una franja concreta y perfectamente identificable de problemas. El error no es usar Redux; es usarlo por defecto o descartarlo por moda. Este nivel entero trata de sustituir el reflejo —Redux para todo, o Redux para nada— por un criterio, y ese criterio empieza reconociendo qué hace Redux mejor que cualquier alternativa ligera, porque solo así sabrás cuándo vale su precio.

El Redux que murió y el que no

Conviene empezar por una amputación conceptual, porque sin ella toda la discusión se enturbia. Lo que la industria enterró entre 2020 y 2026 no fue Redux, sino su ergonomía original: los creadores de acciones escritos uno a uno, los tipos de acción como constantes de texto, los switch gigantes en cada reducer, la instalación por separado de redux-thunk y el ritual de tres archivos para incrementar un contador. Aquel Redux artesanal pedía cientos de líneas para lo que hoy resolvemos en diez, y su muerte fue merecida. Redux Toolkit —oficial desde 2019 y estándar indiscutido desde 2021— barrió casi todo ese boilerplate: configureStore reemplaza la configuración manual del store y trae el thunk y las devtools de fábrica, y createSlice genera acciones y reducer a partir de una sola declaración, con Immer integrado para que puedas escribir mutaciones aparentes sobre un estado que por debajo sigue siendo inmutable.

import { configureStore, createSlice, type PayloadAction } from '@reduxjs/toolkit'

const contador = createSlice({
  name: 'contador',
  initialState: { valor: 0 },
  reducers: {
    // Immer permite "mutar": por debajo produce un estado nuevo inmutable
    incrementar: (state) => { state.valor += 1 },
    sumar: (state, action: PayloadAction<number>) => { state.valor += action.payload },
  },
})

export const { incrementar, sumar } = contador.actions
export const store = configureStore({ reducer: { contador: contador.reducer } })

Ese bloque es Redux entero: un estado, unas transiciones puras y unas acciones que las disparan. No hay constantes de texto, no hay switch, no hay Object.assign defensivo para no mutar. La diferencia con 2016 no es cosmética: es la diferencia entre una herramienta que castigaba su uso correcto y otra que lo vuelve el camino de menor resistencia. Por eso, cuando alguien dice hoy que Redux es puro boilerplate, casi siempre recuerda una herramienta que ya no existe. La pregunta legítima de 2026 no es si Redux es ergonómico —lo es—, sino si su modelo mental compensa frente a alternativas que piden todavía menos.

Los cuatro argumentos que todavía lo sostienen

RTK no gana por defecto, pero gana con claridad en cuatro escenarios que conviene poder nombrar sin titubear, porque son la única justificación honesta para elegirlo en un proyecto nuevo.

De los cuatro, el primero es el que más se malinterpreta, así que merece precisión. La ceremonia de Redux —la indirección de despachar una acción para cambiar un valor— es un coste puro para quien programa solo y una ventaja neta para un equipo de cuarenta personas. La razón es que en un equipo grande el enemigo no es la verbosidad, sino la divergencia: si cada quien resuelve el estado a su manera, el código se vuelve un museo de estilos incompatibles que nadie mantiene. RTK colapsa ese espacio de decisiones a una sola respuesta —así se define un slice, así se muta, así se selecciona— y esa uniformidad impuesta es exactamente lo que una base de código con mucha rotación necesita. Lo que para un individuo es una jaula, para una organización es una gramática compartida.

Los patrones estrictos importan cuando el estado modela un dominio en el que un cambio silencioso es inaceptable: cada mutación pasa por una acción con nombre, cada acción por un reducer puro, y el conjunto deja un rastro que puedes registrar, auditar y testear en aislamiento. Esa disciplina, que a un prototipo le sobra, a un sistema de trading o a un historial clínico le resulta barata frente al coste de un estado que cambió sin que nadie sepa cómo.

El viaje en el tiempo no es un truco: es una consecuencia

El time-travel se cita como una curiosidad de demo, y por eso se subestima. En realidad es la propiedad más profunda del modelo y la que ninguna alternativa ligera reproduce del todo, porque no es una funcionalidad que Redux añada, sino una consecuencia matemática de dos decisiones de diseño. Primera: el estado siguiente es una función pura del estado anterior y una acción, (estado, accion) -> estado, sin efectos ocultos. Segunda: las acciones son objetos planos y serializables, no closures ni referencias. Junta ambas y obtienes algo poderoso: la historia completa de tu aplicación es la lista de acciones, y cualquier estado pasado se recupera reproduciéndolas desde el inicial.

flowchart LR
UI[vista] -->|dispatch accion serializable| R[reducer puro]
R -->|estado siguiente| S[store unico]
S -->|re-render| UI
S -.registro de acciones.-> DT[devtools]
DT -.salto a cualquier estado pasado.-> S
style S fill:#cba6f7,color:#11111b
style DT fill:#f9e2af,color:#11111b

La consecuencia práctica es enorme para la clase de bug más cara que existe: la que no puedes reproducir. Si un usuario encuentra un fallo, el registro serializado de acciones que llevó a ese estado se exporta, se adjunta a un reporte y se reproduce paso por paso en tu máquina. Zustand con su middleware devtools se asoma a esto, pero la garantía es más débil, porque nada en Zustand te obliga a que cada cambio pase por una acción serializable: puedes mutar el store desde cualquier sitio y romper el registro sin enterarte. En Redux esa disciplina no es opcional, y por eso el viaje en el tiempo es fiable. La lección general trasciende a Redux: algunas propiedades valiosas solo emergen de restricciones que se pagan por adelantado, y renunciar a la restricción es renunciar también a la propiedad.

RTK Query: la cache que vive dentro del store

El cuarto argumento merece su propia sección porque toca directamente el tema del nivel siguiente. RTK Query es la respuesta de Redux al estado del servidor: un módulo que declara endpoints, cachea por clave, deduplica peticiones, revalida e invalida tras mutaciones —justo el trabajo que en el Nivel 32 vimos hacer a TanStack Query—.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react'

export const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  tagTypes: ['Usuario'],
  endpoints: (build) => ({
    getUsuario: build.query<Usuario, string>({
      query: (id) => `/usuario/${id}`,
      providesTags: (_r, _e, id) => [{ type: 'Usuario', id }],
    }),
    renombrar: build.mutation<Usuario, { id: string; nombre: string }>({
      query: ({ id, nombre }) => ({ url: `/usuario/${id}`, method: 'PATCH', body: { nombre } }),
      // al mutar, invalida la clave y RTK Query revalida sola
      invalidatesTags: (_r, _e, { id }) => [{ type: 'Usuario', id }],
    }),
  }),
})

export const { useGetUsuarioQuery, useRenombrarMutation } = api

La pregunta no es si RTK Query es bueno —lo es— sino cuándo elegirlo frente a TanStack Query. La respuesta es de coherencia, no de features: si tu aplicación ya vive en Redux por alguno de los tres argumentos anteriores, RTK Query te da la cache de servidor dentro del mismo store, con las mismas devtools y el mismo modelo mental, y sumar TanStack Query sería introducir un segundo sistema de estado con su propia filosofía. Si, en cambio, no tienes una razón fuerte para Redux, TanStack Query es más completo, agnóstico del framework y no te ata a un store global. Dicho de otro modo: RTK Query no es una razón para adoptar Redux; es una recompensa para quien ya lo adoptó por otros motivos.