Flux/Alt data dependency, how to handle elegantly and idiomatically

Question

I'm using alt as my flux implementation for a project and am having trouble wrapping my head around the best way to handle loading stores for two related entities. I'm using sources feature along with registerAsync for to handle my async/api calls and bind them to my views using AltContainer.

I have two entities related one to one by the conversationId. Both are loaded via an api call:

Once my job store is loaded with data I want to fill a conversation store.

I use a source to load the job store:

module.exports = {
    fetchJobs() {
        return {
            remote() {
                return axios.get('api/platform/jobs');

            },....

Seems like a job for the waitFor() method, but it seems for use when the contents of one store require a transformation or merging with the contents of another. I need to fetch the contents of one data store based on the contents of another.

In general terms I need to:

• Call a third party API and load a list of entities into a store.
• When that data arrives I need to use attribute from each of the above to call another API and load that data into another store.

My naive solution is to reference the conversation actions from the job store and to dispatch an event when the data arrives. Something like this:

var jobActions = require('../actions/Jobs');
var conversationActions = require('../actions/Conversations');

class JobStore {
    constructor() {
        this.bindListeners({
            handlefullUpdate: actions.success
        });...

    }

    handlefullUpdate(jobs) {
        this.jobs = jobs;
        conversationActions.fetch.defer(jobs);
    }
}

Of course, doing this, violates the dictum that stores shouldn't dispatch events, and so I must use defer to dispatch an action in the middle of a dispatch. It makes sense to me, since it seems in going down this path I'm reintroducing all sorts of side effects in my code; losing the beauty of the "functional pipelines" that I should be seeing with flux.

Also, my job store has to hold a reference to any dependent entities so it can dispatch the appropriate action. Here I have only one, but I could imagine many. In terms of the dependencies between entities this seems totally backwards.

A couple of alternatives come to mind:

I can call the api/platform/jobs endpoint in the source/action where I fetch all conversations, just to get the id. The original approach is more efficient, but this seems truer to the spirit of flux in that I lose all the cross-talk.

I could also have single action/source that fetches both, returning {jobs:{}, conversations: in the action} (orchestrating the dependency there using promises) and use this populate both stores. But this approach seems unnecessarily complicated to me (I feel like I shouldn't have to do it!).

But am I missing another way? It seems strange that such a common use case would break the elegance of the flux paradim and/or forces me to jump through so many hoops.

@dougajmcdonald posed a similar question here, but maybe it was phrased too generally, and didn't get any traction:

Answer 1

This definitely seems like a flaw in the Flux design, and you're right, it is a very common use case. I've been researching this issue (and a few similar ones) for a few days now to better implement Flux in my own system, and while there are definitely options out there, most have drawbacks.

The most popular solution seems to be using Containers, such as AltContainer, to abstract away the task of data requesting from apis and loading from stores into a single component, absent of ui-logic. This Container would be responsible for seeing the information from the stores and determining if additional actions are required to make them complete. For example;

static getPropsFromStores() {
    var data = SomeStore.getState();
    if (/*test if data is incomplete */){
        SomeAction.fetchAdditionalData();
    }
    return data;
}

It makes sense. We have the logic and component in our Component layer, which is where Flux says it belongs.

Until you consider the possibility of having two mounted containers asking for the same information (and thus duplicating any initialization fetches, i.e. conversations in your model), and the problem only gets worse if you add a third (or fourth, or fifth) container accessing those same stores.

The canned response to that from the Container crowd is "Just don't have more than one!", which is great advice... if your requirements are ok with that.

So here's my altered solution, around the same concept; Include one Master Container/Component around your entire application (or even beside it). Unlike traditional containers, this Master Container/Component will not pass store properties to its children. Instead, it is solely responsible for data integrity and completion.

Here's a sample implementation;

class JobStore {
    constructor() {
        this.bindListeners({
            handleJobUpdate: jobActions.success
        });

    },

    handleJobUpdate(jobs) {
        this.jobs = jobs;            
    }
}

class ConversationStore {
    constructor() {
        this.bindListeners({
            handleJobUpdate: jobActions.success,
            handleConversationUpdate: conversationActions.success
        });

    },

    handleJobUpdate(jobs) {
       this.conversations = {};
       this.tmpFetchInfo = jobs.conversation_id;
       this.isReady = false;

    },

    handleConversationUpdate(conversations) {
       this.conversations = conversations;
       this.tmpFetchInfo = '';
       this.isReady = true;
    }

}

class MasterDataContainer {

    static getPropsFromStores() {
        var jobData = JobStore.getState();
        var conversationData = ConversationStore.getState();

        if (!conversationData.isReady){
            ConversationAction.fetchConversations(conversationData.tmpFetchInfo);
        }  
    },

    render: function(){
        return <div></div>;
    }
}