Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call cb if provided to send even if callOnError was true #44

Open
anandthakker opened this issue Jul 6, 2016 · 5 comments
Open

Call cb if provided to send even if callOnError was true #44

anandthakker opened this issue Jul 6, 2016 · 5 comments

Comments

@anandthakker
Copy link

If I've created a send with createSend('blah', true) -- so that errors go to the store's onError handler -- I might also want to use send asynchronously. @yoshuawuyts what do you think about including an if (cb) { cb(err) } at the end of onErrorCallback (L131 on master)?

@yoshuawuyts
Copy link
Owner

@anandthakker could you write a quick patch for this? I think it'll make more sense once I see it - Main use case for passing true to createSend() was so reducers and views don't like need to call done() all the time.

Perhaps a possible solution would be to call createSend() twice? - but I'm keen to see what you mean. Thanks!

@anandthakker
Copy link
Author

@yoshuawuyts yep, see ^. My use case here is that I want to use onError to set up an app-wide default error handler, even in cases where I might be using send asynchronously

@yoshuawuyts
Copy link
Owner

Ah, but so at the top level onError is always called; the first caller should generally come from a view (or technically onStateChange()) which gets the onError hook attached. If every caller propagates errors upwards using send(name, data, (err, res) => {}) and done(err, res) eventually the global onError() handler will be called - both with sync and async calls.

Does that make sense?

@yoshuawuyts
Copy link
Owner

@anandthakker is this still an issue? Any way I can assist?

@anandthakker
Copy link
Author

Ah -- I've managed to move along okay without it, but it's sometimes
required the hack of passing a synchronous "send" as part of the payload to
an effect (since the effect's send is async). So, I guess that's just to
say, it's not a blocker for me, but I've still got a use case for it. Okay
with closing if this is not a direction you want to take it in

Why do I have effects that need a synchronous "send"? Because I'm actually
using a model to manage mounting / rendering / unmounting a bunch of
independent views, and so the "views:render" effect needs a sync send that
it can pass along to the view functions.

On Mon, Jul 18, 2016 at 8:27 AM Yoshua Wuyts [email protected]
wrote:

@anandthakker https://github.com/anandthakker is this still an issue?
Any way I can assist?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#44 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEvmR2VKxqMNXoSC-HbUZ7HdixyFOn2lks5qW3EugaJpZM4JGAEb
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants