La ontología de Flux y Redux
El mapa mental del flujo unidireccional en la web: de Flux a Redux Toolkit, el middleware, los selectores, RTK Query y la ola ligera de Zustand, Jotai y Valtio.
En 2014 Facebook tenía un problema que sonaba absurdo para una empresa de su tamaño: el contador de mensajes no leídos se equivocaba. No por un cálculo mal hecho, sino porque en un MVC con enlaces bidireccionales nadie podía decir con certeza quién había cambiado qué y en qué orden. La respuesta fue Flux: obligar a que los datos viajen en una sola dirección. Diez años después esa idea gobierna medio frontend, ha sido copiada por Swift y por Kotlin, y ha empezado a ceder terreno ante herramientas más ligeras. Este mapa recorre esa historia completa.
- Ver el mapa mental completo de Flux, Redux y sus sucesores.
- Entender qué problema resolvió el flujo unidireccional y a qué precio.
- Situar el middleware, los selectores y RTK Query.
- Conocer la ola ligera (Zustand, Jotai, Valtio) y cuándo elegir cada cosa.
El territorio, de un vistazo
mindmap
root((Flux y Redux))
El patron
Flujo unidireccional
Action
Reducer
Store
Redux Toolkit
createSlice
configureStore
createAsyncThunk
RTK Query
Efectos
Thunk
Saga
Listener
Lectura
Selectores
Reselect
Normalizacion
DevTools
La ola ligera
Zustand
Jotai
Valtio
Practica
Testing
Estructura
Rendimiento
MigracionLas ideas clave
Una sola dirección
Acción, reducer, store, vista. Siempre en ese orden y nunca al revés. Esa restricción es todo el aporte de Flux: renunciar a la comodidad de mutar desde cualquier sitio a cambio de poder razonar sobre el sistema.
El cambio deja rastro
Cada acción es un objeto con nombre. Puedes registrarlas, repetirlas, viajar en el tiempo. Las DevTools de Redux convirtieron esa propiedad en una herramienta que sedujo a toda una generación.
La ceremonia tuvo un coste
Redux pedía tres archivos para incrementar un contador. Redux Toolkit lo arregló, pero para entonces ya había nacido una ola de alternativas de tres kilobytes que se llevaron el mercado.
El servidor cambió el mapa
Cuando TanStack Query se llevó el estado del servidor, al store global le quedó mucho menos trabajo. Ese es el motivo real por el que Redux dejó de ser la respuesta por defecto.
Por qué importa
Los números de 2026 cuentan una historia que suena a declive: Redux baja del 57% al 38% de uso mientras Zustand casi triplica el suyo. Pero leer eso como “Redux fracasó” es entender justo al revés lo que pasó. Redux impuso su tesis con tal éxito que dejó de hacer falta como librería. Hoy nadie discute que el estado deba ser inmutable, que las mutaciones deban ser explícitas y trazables, o que el flujo deba ir en una sola dirección: eso es sentido común del oficio, y lo es porque Redux lo predicó durante una década. Lo que envejeció no fue la idea sino su implementación: el boilerplate de los primeros años, y sobre todo el supuesto de que todo el estado de la aplicación debía vivir en un único store. Ese supuesto se rompió cuando quedó claro que la mayor parte de lo que guardábamos ahí no era estado nuestro, sino una copia del estado del servidor —y que una copia de datos remotos no es estado, es una cache, con problemas propios de invalidación, frescura y reintentos que un reducer nunca supo resolver bien—. Al llevarse esa mitad a TanStack Query, al store global le quedó el trozo pequeño: el tema oscuro, el carrito, el usuario actual. Y para ese trozo, tres kilobytes de Zustand bastan. La lección que este track persigue no es cuál librería elegir, sino aprender a ver la diferencia entre una idea arquitectónica —que perdura— y su encarnación concreta —que caduca—.
El camino
- Niveles 1–7 · Fundamentos — Flux, Redux, Redux Toolkit, middleware y efectos, selectores, la ola ligera y el criterio.
- Niveles 8–11 · Redux a fondo — DevTools y time travel, RTK Query, redux-saga, y el testing.
- Niveles 12–13 · Estructura — organizar un Redux grande y tiparlo bien con TypeScript.
- Niveles 14–17 · La ola ligera — Zustand, Jotai y Valtio a fondo, y cómo migrar entre ellos.
- Niveles 18–23 · Práctica y perspectiva — fuera de React, rendimiento, persistencia, patrones avanzados, errores y síntesis.
- Abre un proyecto con un store global y clasifica su contenido: ¿qué es estado propio del cliente y qué es una copia del servidor?
- Calcula qué proporción es cada cosa. Si más de la mitad viene del servidor, ya sabes por dónde empezar a simplificar.
- Busca en ese código el último bug de estado que arreglaste: ¿lo habría evitado el flujo unidireccional, o era un problema de cache?
- Comprométete con la distinción: la idea (unidireccional, inmutable, trazable) es permanente; la librería, una elección revisable.