* 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
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 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
And it is in the redux tutorials, but buried in the advanced section. http://redux.js.org/docs/advanced/AsyncActions.html
[1] https://github.com/jmakeig/redux-thunk-scaffolding/blob/mast...
"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.