Consider an isomorphic application based on Flux, and using the Fluxible library to do it. You have a React email application, with a list of messages on the left, and the current open message on the right.
Your router triggers the 'SHOW_POST' action when it gets called with the URL '/message/123' and the action loads the data, updates the store, and thus the message appears on the right. This all works, the navigation promise is resolved and the page rendered.
However, the page is rendered without the list of messages on the left. If the action to 'LOAD_ALL_MESSAGES' is called during SHOW_POST, they are not actually rendered on server, the server returns an empty list and they are loaded in via AJAX on the client.
How to populate other stores on the page for which other components require. I tried calling actions to populate them when the components that require them are rendered, this seems unclean, and doesn't solve the issue of the component not being rendered server side.
It seems equally unclean to have to trigger additional actions to populate stores in all the navigation actions, as the stores might not be needed, the code would be repetitive as I would need to call these populate actions from nearly all the various navigation actions.
What's the preferred architecture to populate background stores during server side rendering. Trigger multiple actions from within each navigation and wait for them all to be resolved?
This is the approach I follow,
The action method of such routes(requiring data from multiple stores) looks like this:
action: function (context, payload, done) {
var getXData = new Promise(function(resolve){
context.executeAction(getXDataAction, {}, resolve);
});
var getYData = new Promise(function(resolve){
context.executeAction(getYDataAction, {}, resolve);
});
Promise.all([getXData, getYData]).then(function() { done() });
}Inside those actions I check if the data already exist, in relevant stores, to avoid fetching it externally.
Alternatively, you can create another action creator and just move the logic out from route to the action creator. I don't see real benefit in it apart from keeping your routes lean.