Hacker News Reader

Comment by rbalicki | Hacker News Reader

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.

View on HN

As 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

Check out flux standard actions for even more consistency:

https://github.com/acdlite/flux-standard-action

One 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.

Thanks! Didn't know about this library, but it's good to see that others are thinking about this too

Not 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.

I 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

It 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

I created a quick code generator[1] for async action scaffolding just for this reason.

[1] https://github.com/jmakeig/redux-thunk-scaffolding/blob/mast...

Reply on news.ycombinator.com