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

Making a case for .catch #62

Open
duro opened this issue Nov 22, 2017 · 0 comments
Open

Making a case for .catch #62

duro opened this issue Nov 22, 2017 · 0 comments

Comments

@duro
Copy link

duro commented Nov 22, 2017

Noticed this in the the middleware src:

// NOTE(lmr):
// it's debatable whether or not we want `.then(success, failure)`
// versus `.then(success).catch(failure)`

Well, I'd like to spark that debate. Right now this is working completely contrary to the Promise spec, which is making the promise returned from the action creator not play nicely with other libraries, and making chaining off of it pretty unintuitive.

I understand that chaining off the action creator is not something that should be done heavily, but sometimes (and especially in the case of an error) it is ideal to be able to handle the error case at the point of action creator invocation.

I have found that storing error states in the store can lead to issues where error messages persist for the entire life of the app, even though they should be ephemeral.

My preference for the ephemeral case is to handle that catch in the component layer, rather than in at the store layer.

Thoughts?

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

1 participant