Redux Saga vs Thunk: What should you choose?
HTML-код
- Опубликовано: 3 авг 2021
- 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. 
Наука
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.
Yes, that's what I was thinking too
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
that's excatly i was gonna write here buddy, i also have used multiple fetch requests many time with async or await
Yep, either that or using also RxJS Observables, it makes life way easier too.
Yes definitely, and if he wanted to avoid chaining or nesting, he could use async/await
Instead of using .then why can we use async await for avoiding callback hell??
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 :)
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
Pretty clean tutorial!! Finally found a Saga / Thunk tutorial which explains things in a simple fashion.
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.
Great explanation! Good job man.
Your videos are very enjoyable!
Thank you!! great job 🙏🙏
A very good one. I watched it cause there are no other videos on this subject with a source code
Can't we use async await syntax for call back hell or dependency problem
u can use async/await also right?
what u did for saga
Hm...so if we know how to use async await or Promise.all() then there is no need for saga right?
Thank you for this video
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?
super helpful vid!
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
cause reducer is a pure function?
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 👍
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.
ED ROHHHH!!!
good tutorial, you made redux-sage very simple :3
😇😇😇
great video
isnt saga deprecated
Nice video
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.
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.