can anyone enlighten me on why redux saga is useful when we can already have redux thunk where can use async and await.
what does yeild and generator functions do something extra that we cannot do on redux thunk ?? . I am really curious
I tried googling but did not find a clear answer
Laymans terms will be appreciated
They’re just a different way of dealing with asynchronous calls. Redux thunk is very simple, both in code terms and conceptually (the library is tiny, basically just a few lines of code). It normally needs quite a bit of boilerplate code written to cover complex asynchronous scenarios.
Sagas are quite complex up front, there’s quite a bit to learn, but then they can make it easier to build out complex asynchronous scenarios.
Yeah, I was in a similar boat a few years ago - I’d used thunks but got hired on somewhere where they used sagas.
Yeah sagas looked like a mountain of unnecessary complexity. But after I got used to them, I realized that it was easier to do more complex things and to break it down into more readable code.
A lot of libraries are going to seem bizarre at first. Just stick with it,
Exactly the same for me – I was given an app that used sagas without having used them at all (just looked at the docs a few times in the past and discounted them as they looked too complicated).
@swagathshetty note that generators are a bit different to most other things in JS – if you’ve used another language has them built in, and used them in that language (Python, Ruby for example), then I suspect they’d seem quite natural. I’d used Ruby before JS, but had never really touched Enumerators directly, so generators were a bit strange. But by time used sagas was quite familiar with them so it made sense. I’m not sure how I would feel if I was approaching sagas without understanding generators, how much difference it makes
My understanding of sagas is that they’re for compounding multiple related operations into a single (non-atomic) transaction. The classic example is travel booking, where in one go you need to reserve a flight, car, and hotel. They all have to happen or none of them do. Each step is done separately and each has a well-defined “undo” operation. So if the flight and car bookings succeed but the hotel booking bombs out, you undo the other two bookings and return a failure.
redux-saga is actually a lot more generic than the historical definition of the saga pattern, but it provides the foundation for the general idea: side effects are confined to a single execution “thread” (abstractly, not a real thread), and failures are handled gracefully.
It’s a higher-level thing than thunks, with nicer syntax, but they can both express the same concepts. The two work together just fine, though I’m not sure if it’s common idiom to use both (I’m a Vue guy and I just sling around refs instead of using state managers)
Yep, that’s what it’s best at afaics. eg in aforementioned app I have to check network connections, then make calls for tokens, then configure the API with the token and check authed, then make an actual API call, then handle various different failure scenarios.
Personally, I prefer not to use Redux for any async logic, just have the logic for the call on the front end in specialised loader components, and if I need Redux, just use it as a data store I can serialize. I hate having stuff that isn’t data (like loaded/error etc flags) in what is basically a database. But hey ho