Qué pasa con Redux y por qué hoy casi nunca lo necesitas

Redux fue durante muchos años la solución por defecto para gestionar estado global en aplicaciones React. Mucha gente lo aprendió, lo usó en producción y lo asoció directamente a React.

Pero el ecosistema ha cambiado mucho.

En esta clase vamos a ver qué es Redux realmente, por qué se hizo tan popular y, sobre todo, por qué hoy en día suele ser una mala elección para la mayoría de proyectos nuevos.

¿Qué es Redux realmente?

Redux no es una biblioteca de React.

Redux es una biblioteca de JavaScript para gestionar estado global, que puedes usar con React, Angular, Vue, puramente con JavaScript, o con cualquier otro framework o sin ninguno.

Lo que pasa es que se hizo famosa en React, y por eso mucha gente piensa que es “parte” de React.

Para React existe un paquete específico react-redux que facilita la integración. Pero Redux como concepto es independiente del framework.

Por qué Redux fue tan popular

Redux apareció en un momento donde React no tenía buenas herramientas para estado global.

Antes de Context API:

• Todo el estado vivía arriba.
• Se pasaban props de componente en componente.
• El famoso prop drilling.

Redux solucionaba varios problemas:

• Un único estado global.
• Flujo de datos predecible.
• Cambios controlados.
• Debugging potente.

En su momento, era una gran solución.

El gran problema de Redux hoy

Redux ha envejecido mal. No porque funcione mal, sino porque:

• Es grande.
• Tiene mucho boilerplate.
• Obliga a aprender muchos conceptos.
• Introduce jerarquías innecesarias.

Conceptos que tienes que aprender

• Store
• Actions
• Reducers
• Dispatch
• Middleware
• Selectors
• Normalización del estado
• Convenciones estrictas

Para muchos proyectos modernos, es demasiado.

Redux vs Context API

Con la llegada de Context API, React empezó a cubrir gran parte de los casos donde antes se usaba Redux.

Context permite:

• Compartir estado sin prop drilling.
• Tener múltiples providers.
• Consumir estado desde cualquier componente.

Visualmente, el cambio es clave:

Antes (prop drilling)

App
 └── Layout
     └── Page
         └── Header
             └── Button

El estado se pasa de arriba abajo, aunque solo lo necesite el botón.

Ahora (Context)

<AuthProvider>
  <App />
</AuthProvider>

Cualquier componente dentro puede acceder al estado directamente.

El Provider como “caja”

Una buena forma de entender Context es pensar en el Provider como una caja.

• El Provider guarda el estado.
• Los componentes “leen” lo que necesitan.
• No importa dónde estén en el árbol.

<AuthContext value={value}>
  <App />
</AuthContext>

Cualquier componente dentro puede hacer:

const { isLogin, login, logout } = use(AuthContext)

Sin pasos intermedios.

¿Un solo Provider o muchos?

Puedes tener tantos providers como necesites.

Ejemplos habituales:

• AuthProvider
• FavoritesProvider
• ThemeProvider
• Router Provider (React Router)

No hay un límite real.

<AuthProvider>
  <FavoritesProvider>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </FavoritesProvider>
</AuthProvider>

De hecho, React Router es un provider. Por eso puedes usar useLocation, useNavigate, etc.

El problema del “provider hell”

Cuando empiezas a tener muchos providers anidados, aparece el famoso:

• Provider hell
• Context hell

Pero esto solo ocurre en casos muy grandes o mal estructurados.

En la mayoría de proyectos reales:

• 2 o 3 providers
• Totalmente manejable

No es una razón suficiente para introducir Redux.

¿Entonces Redux ya no sirve?

No.

Redux sigue siendo útil en casos muy concretos:

• Aplicaciones enormes
• Estados muy complejos
• Necesidad extrema de trazabilidad
• Equipos grandes con normas estrictas

Pero para la mayoría de proyectos nuevos, no aporta ventajas reales.

Qué usar hoy en lugar de Redux

Hoy en día tienes mejores alternativas:

• Context API + hooks
• Zustand
• Jotai
• Signals
• Stores simples sin boilerplate

Todas ellas:

• Menos código
• Menos conceptos
• Más directas
• Más fáciles de mantener

Recomendación personal

Si hoy tuviera que empezar un proyecto desde cero:

• ❌ No usaría Redux
• ✅ Usaría Context para lo básico
• ✅ Usaría Zustand si necesito algo más potente

Redux no es incorrecto, pero ya no es la mejor opción por defecto.

Resumen de la clase

En esta clase has aprendido:

• Redux no es exclusivo de React.
• Por qué se hizo tan popular.
• Qué problemas tiene hoy.
• Cómo Context soluciona muchos de esos casos.
• Por qué Redux suele ser innecesario.
• Qué alternativas modernas existen.