Redux Saga vs Thunk: What should you choose?

In this video, we compare and contrast Redux Saga and Thunk.
Helpful Links: / redux-middleware-the-d...
-----------
Subscribe to my channel: / @edrohdev
for more algorithm explanations, tech discussions, and programming tutorials!
-----------
Hey there, my name’s EdRoh. On my channel, you will find common coding algorithms and/or interview questions (with explanations of course). I also provide tutorials and courses on other programming topics in Web Development including Javascript, React, HTML, CSS, TypeScript, Redux, Node, Progressive Web Apps, React Native, Flutter, etc.
No matter what level you are, whether you are already in the software engineering field, or are just beginning coding in bootcamp or being self taught, my first and foremost desire is to help you provide with the best teaching content and learning resource I possibly can. As someone who understands the struggles of switching careers, I hope I can help guide you into this difficult but rewarding journey into engineering.

[@KaranKumar-wb5bn]

9:30 you said setting up thunk gets messy. I disagree, it's because you've not structured the code properly for thunk. You're using .then (instead of using async await)and explicit returns and also actions as functions. Instead you'd dispatch the object directly. You can make the code look really neat with thunk.

[@abdelbariomymen7150]

Yes, that's what I was thinking too

[@ApprendreSansNecessite]

I mostly agree, but you are picking my attention with this: "... and also actions as functions. Instead you'd dispatch the object directly.". isn't redux-thunk all about using actions as functions? What am I missing? The problem I see with this code is that one "action" (`getUsersRequest`) is dispatching 2 other actions (`getUserFetch` -which by the way is a synonym of `getUsersRequest`, this is a red flag- and `getUserSuccess`). First of all, I think `getUsersRequest` is knowing too much about the rest of the system: we are not taking advantage of the decoupling that programming with actions allows. At no point is the system reacting to actions, the only thing that is abstracted is the CRUD operation on the store. Second: The code is lying in telling us `getUsersRequest` is an action. It is not. It doesn't need to be dispatched, it could just have been called from within the component (by passing `dispatch` as an argument): it's an overly complicated event handler. If you don't mind Karan, I would be interested to know how you would have written a clean thunk for this

[@ankitkumar3037]

that's excatly i was gonna write here buddy, i also have used multiple fetch requests many time with async or await

[@marian_tsx]

Yep, either that or using also RxJS Observables, it makes life way easier too.

[@sandrosxila]

Yes definitely, and if he wanted to avoid chaining or nesting, he could use async/await

[@defnotathot]

Your videos are very enjoyable! I learned a lot of sagas with you, thanks man. I used to have the same thought that you said "uhhh gotta learn more stuff" - but with time that went away and now I appreciate sagas :)

[@SouravDey55500]

Pretty clean tutorial!! Finally found a Saga / Thunk tutorial which explains things in a simple fashion.

[@bagusamrullah4371]

Thank you for the clear explanation, I have been using Thunk this whole time and wanted to learn about Saga. I'm pretty comfortable using thunk, I feel like it's better in some cases. But knowing saga have plenty built in feature makes me reconsider it for my future project :D

[@calwinstevepaul.k5376]

Instead of using .then why can we use async await for avoiding callback hell??

[@trevedhek4075]

The big advantage of Redux Saga seems to be the built-in helper functions/effects. Other than that, it is difficult to see why: > const response = yield call(fetch url); is an improvement over: > const response = await fetch(url); Also, for a better comparison, I'd like to see a solution that didn't use ANY middleware. It would be interesting to compare readability to thunks and sagas. I suspect it would look a lot like your thunk code.

[@piotrekjazz1287]

A very good one. I watched it cause there are no other videos on this subject with a source code

[@amitthakur5880]

Can't we use async await syntax for call back hell or dependency problem

[@philippeb1039]

Hm...so if we know how to use async await or Promise.all() then there is no need for saga right?

[@roshanlalsahu7846]

u can use async/await also right? what u did for saga

[@nikhilev3840]

On 11.0 you try to prove that consecutive api calls may create a callback hell hence use Saga. Can we use the async/await there?

[@chaoliu2631]

Great explanation! Good job man.

[@hamzaef5281]

Thank you!! great job 🙏🙏

[@mohamedyoussef8835]

Your videos are very enjoyable!

[@codewithabhishek1676]

You can also use async and await for one line of code in case of redux thunk . And you can also use with axios. One more thing is your video is helpful for all , thanks for making such type of video 👍

[@OscarRuiz-ql3bt]

I have a question maybe a little bit stupid, why can't we just use async await on a regular reducer and call again the reducer function if needed? why do we need to use a middleware? by the way great video

[@Opacity5]

cause reducer is a pure function?

[@geebsayshi]

I'm glad I'm not the only one who prefers saga. But you could have used asyn await for thunk to give it a better fight chance.

[@madhousenetwork]

Thank you for this video

[@joemurray1664]

super helpful vid!

[@AnNguyen-uv9yc]

good tutorial, you made redux-sage very simple :3 😇😇😇

[@netsaosa4973]

isnt saga deprecated

[@harmonhuynh]

ED ROHHHH!!!

[@priyanshrawal1144]

great video

[@pujamaity9403]

Nice video

[@lvendrame]

Promise comes to avoid callback hell, then you start a promise hell, why? Just return the new promise and use its return in the next then.

[@stencil25]

I believe that an engineer would benefit more by; - using Thunks with async/await (avoiding callback hell), - applying any async effects themselves (e.g. Throttling). This could include using a lower level lib such as RxJS - which can be applied to more situations, outside of state management. As an engineers, learning how to handle async events is crucial to personal development, and will pay off in the long run.