Re:Two Weird Tricks with Redux
by rbalicki on Wednesday April 13, 2016 @12:59PM
(#11490003)
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
* 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