This message was deleted
try{ console.log('derp') } catch(err){console.log(err)}finally{console.log('yerp')}
gives 'derp' 'yerp'
so no need for an exception to be thrown
(unless an exception is thrown)
Another thing. As far as I can see, when I
emit an Error in an eventChannel and then take from that channel it should throw, right? This doesn’t really work for me. Meaning it just doesn’t throw it seems
Oh now all these names make much more sense
Does anyone know where the docs for multicast are? I would like to look them over, https://redux-saga.js.org/docs/introduction/ doesn't have a section that screams multicast at me
but ask away, the maintainers and users hang out here and are likely to be able to answer your questions
I tried digging through the code recently and I was a little lost.
ah, cool. thanks for the info
hey folks... does anyone happen to have a resource that describes the lifecycle of an action in the context of put/take? I'm having a hard time reasoning about
put vs. putResolve, e.g., so more generally, I'm hoping to find a collection of sequence diagrams or something like that
Hey everyone, small question: Does redux-saga always run its effects synchronously? Or does it sometimes wait to execute its effects. The reason why I'm askin is because I have a case where two actions are called (ACTION1 and ACTION2). ACTION1 is dispatched first and ACTION2 shortly after. Now I need a saga to respond to ACTION1 before ACTION2 hits the reducer but from my console it looks like the saga is triggered when both ACTION1 and ACTION2 are already handled by the reducer.
@trassmann I have a delete acition that calls a confirmation modal that can reject or accept the call. Let's say I clicked delete like five times then clicked no and sixth time clicked yes on the confirmation modal: the generator function calls the API for a delete request (six HTTP requests) - I checked in the network tab in chrome dev tools). It seems to that when clicking "No" the confirmation modal doesn't actually reject the call of the delete generator function.
Danke sehr! :)))
ah nevermind, all is for effects and join is for tasks
but it looks like they do the same thing, essentially
what is the difference between a task and an effect? I found the def of an effect: https://redux-saga.js.org/docs/basics/DeclarativeEffects.html essentially a json obj that will be run by the middleware.
Are you calling the generator functions tasks?
Ah nm, that is what it is
Hi @all, I'm having trouble deciding how to handle global errors on my sagas and I was unable to find an elegant solution to it. Currently all my sagas have a huge try block which sends errors to sentry in its catch block if there's any error. Can someone please suggest me any better solution for this? I even followed up a few issues on the GitHub repo and stackoverflow but unfortunately I couldn't find something I can say can be considered as best practice. So I wanted to know how everyone else handles this. Any help, advice or suggestion is appreciated! Thanks in advance and I hope everyone is having a nice day!
This doesn't surprise me, the nature of saga calls makes me think more of error catching on an individual basis. If you are hitting an api, then you'll have to deal with 400 etc. That type of thing should probably be dealt with on a case by case basis. If you are looking for a global catch-all, I found this in github: redux-saga/redux-saga#1672
It might correspond to your needs @rishichawda
Also, I'm using
apisauce for calls to my api server so everything in the requests part is handled very well right now. What I wanted to do is make sure I handle possible scenarios that might happen in the production which cannot be reproduced so well manually. Like what if there's an inconsistent state or what if the data is corrupted or what if something happens on put or call. I need to handle those errors too. I'm not concerned about anything breaking in the UI since I'm having error boundaries for them but I need to make sure everything works fine with sagas too. Right now I pretty much have one try catch block in every saga which kind of feels redundant and doesn't look pretty to me. So I was looking for an elegant way to do that.
How do you handle errors in your saga btw? @unflores
@rishichawda we catch them in individual sagas. For me that makes the most sense, anything that gets up to the mainSaga error handler is more of a "catastrophic" error, I don't want to handle it b/c I wasn't expecting it. I just want to log it somewhere so I can deal with it later. I treat it as equivilant to a 500 from an api.
@rishichawda I've been looking for something solid like this