4 ms·
What stuck out to me is "In an asynchronous world, you have 3 actions indicating asynchronous work: start, done, and error. In our system, they all are of the
by rbalicki 11y ago
What stuck out to me is
"In an asynchronous world, you have 3 actions indicating asynchronous work: start, done, and error. In our system, they all are of the same type (like ADD_BREAKPOINT) but the status field indicates the event type."
This is a great suggestion (I have used a very similar schema before, although in flux), and should be the standard suggestion in redux tutorials.
Not enforcing this can lead to a proliferation of inconsistently named constants, especially if a team is learning flux/redux and has not yet settled on a naming schema.
- bdavisx 11y agoCheck out flux standard actions for even more consistency: https://github.com/acdlite/flux-standard-action https://github.com/acdlite/flux-standard-action
- renke1 11y agoOne problem I have with standard action is that on failure I sometimes want to have more than just an Error as payload. Something like `payload: {error, seqId}`. You could add it to error itself, but I find it more consistent to put it into the payload directly.
- rbalicki 11y agoThanks! Didn't know about this library, but it's good to see that others are thinking about this too
- mdc2161 11y agoIt works great, too, for abstracting away fetch logic to middleware (as in this blog post) or to a shared module. And it is in the redux tutorials, but buried in the advanced section. http://redux.js.org/docs/advanced/AsyncActions.html http://redux.js.org/docs/advanced/AsyncActions.html
- resu_nimda 11y agoNot enforcing this can lead to a proliferation of inconsistently named constants Can you explain this further? Our team uses the ACTION, ACTION_SUCCESS, ACTION_FAILURE pattern, and we haven't run into any issues. I like it because it's a bit easier to parse the sequence of actions in the console at a glance, and async actions are more clearly distinguished from synchronous ones. The main downside is having a bit more boilerplate.
- rbalicki 11y agoI think that's a good pattern, which is to say I think you're enforcing it correctly. I think that as a follow up, you might consider whether stores should respond to multiple ACTION's. You may find that all of the actions are forms of "take this item with id: X and replace it with this updated item" or an array of such commands
- jmakeig 11y agoI created a quick code generator[1] for async action scaffolding just for this reason. [1] https://github.com/jmakeig/redux-thunk-scaffolding/blob/master/template.js https://github.com/jmakeig/redux-thunk-scaffolding/blob/mast...
- rbalicki 11y agoAs a follow-up, one alternative method I have been exploring for solving the author's problems (an alternative to wait-service) is as follows: * if the action creator is passed a UUID, it includes that UUID in all of the start|succeed|error events it dispatches. * There is a request store that sits on top of the base store, which watches for events with UUIDs. If it finds one, it stores in its own map UUID => { state: start|succeed|done, IDs: [Array of IDs that came back from the AJAX request] } * the request store exposes UUID => { state, array of resources } (i.e. it talks to the base store for you) * Components that know exactly which resource they need (e.g. id=1) continue listening to the base store * Components that want the results of an ajax call pass a new UUID every time their filter state changes, and thus can be certain that their UI matches the data they are displaying