Cuando trabajas con Redux y necesitas manejar peticiones asíncronas, Redux Thunk y Redux Saga aparecen como las dos alternativas de middleware más comunes. Aquí entiendes cuándo conviene cada uno, qué los diferencia y por qué Thunk suele ganar en proyectos reales.

¿Qué es un middleware en Redux y para qué sirve?

Un middleware es una capa intermedia que intercepta las acciones antes de que lleguen al reducer. Esto te permite ejecutar lógica adicional, como peticiones asíncronas, registrar logs o transformar datos en el camino.

En el módulo construiste tus propios custom middlewares: uno que registraba un log de cada acción disparada y otro que añadía un Pokémon personalizado a la lista. Después integraste Redux Thunk para que las peticiones asíncronas pudieran resolverse antes de tocar el reducer.

¿Qué hace un middleware en Redux? Intercepta las acciones entre el dispatch y el reducer, permitiendo ejecutar lógica asíncrona o efectos secundarios sin romper el flujo de Redux.

¿Cuál es la diferencia entre Redux Thunk y Redux Saga?

Ambos resuelven el mismo problema: manejar asincronía dentro de Redux. Pero lo hacen con filosofías muy distintas, y eso impacta tanto en la cantidad de código que escribes como en la curva de aprendizaje.

¿Por qué Redux Thunk tiene menos boilerplate?

Thunk es directo: una función que recibe dispatch y ejecuta lógica asíncrona. Punto. Escribes menos código para llegar al mismo resultado y la curva de aprendizaje es suave, ideal si vienes empezando con Redux.

Saga, en cambio, te pide aprender dos conceptos nuevos antes de ser productivo:

• Funciones generadoras (function*), que pausan y reanudan su ejecución.
• Efectos como call, put o take, que describen qué debe hacer Saga en cada paso.
• Una arquitectura basada en watchers y workers que separa la escucha de acciones de su ejecución.

Esa fricción inicial es real. Por eso muchos equipos eligen Thunk para moverse rápido.

¿Cuándo conviene usar Redux Saga por escalabilidad?

Saga gana terreno cuando el proyecto crece. Una de sus funciones más potentes es takeLatest, que cancela ejecuciones anteriores de una misma acción y solo conserva la última. Eso evita problemas clásicos como dobles peticiones cuando un usuario hace clic varias veces seguidas.

Si tu aplicación maneja flujos asíncronos complejos, race conditions o necesitas cancelar tareas en curso, Saga ofrece herramientas que Thunk no tiene de forma nativa.

¿Qué es takeLatest en Redux Saga? Es una función que asegura que solo se ejecute la última instancia de una acción, cancelando las anteriores. Útil para evitar peticiones duplicadas.

¿Qué middleware usar en un proyecto real de Redux?

En la práctica laboral, Thunk aparece en muchos más proyectos que Saga. La razón es simple: para la mayoría de casos de uso (llamar una API, guardar la respuesta, mostrar un error) Thunk es suficiente y más rápido de implementar.

Algunos criterios para decidir:

• Elige Thunk si tu equipo es nuevo en Redux, el proyecto es pequeño o mediano, y los flujos asíncronos son lineales.
• Elige Saga si necesitas controlar cancelaciones, tareas paralelas, debouncing o flujos asíncronos complejos.
• Aprende ambos si trabajas en consultoría o cambias de proyecto con frecuencia, porque te vas a topar con los dos.

Saber moverte entre ambos middlewares te da flexibilidad. No es Thunk versus Saga: es entender cuál encaja mejor con el problema que tienes enfrente.

¿Has trabajado con algún otro middleware de Redux? Cuéntame en los comentarios cuál usaste y qué ventajas le encontraste.