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

后端 未结 3 1720
猫巷女王i
猫巷女王i 2021-01-17 18:55

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 usi

3条回答
  •  慢半拍i
    慢半拍i (楼主)
    2021-01-17 19:27

    I've been looking at @gravityplanx's answer, but am not sure how much it improves the situation.

    To reiterate and amplify: I really, really like the alt pattern of loading my stores from a source. Every component that needs a store(s) looks something like so:

    export default class extends React.Component {
        componentDidMount() {
            CurrentUser.fetch();
            Jobs.fetch(); 
        };
        render() {    
            return(
              
                   
              )
        }
    
    }
    

    The intent is understandable at a glance. And I get a clean separation of concerns, making it easier to test my actions/stores, and sources.

    But the beautiful pattern breaks down in the common use case from my question, and I wind up having to create some fairly complicated plumbing in my actions and stores to orchestrate the ajax calls for the conversations. The other answer seems to just shift this complexity elsewhere. I want it gone.

    What I wound up doing was to completely separate the stores (the first solution suggested in the question). I make an extra ajax call to fetch the conversationId off the job and another to fetch the conversations in the JobConversation source. Something like this:

      axios.get(window.taxFyleApi + 'api/platform/active-jobs-pick/layerConversation?jobId=' + jobId)
                .then((res)=> {
                    let job = res.data[0];  //Returns an array with only one item
                    let qBuilder = window.layer.QueryBuilder.messages().forConversation(job.conversationId)...
    

    I preserve the nice way of using AltContainer with my components and lose all the orchestration plumbing. Right now, I think the resultant clarity is worth the extra back end call.

    I also realize how I'd LIKE it to work (in terms of notation), and will ask @goatslacker about, or may take a shot at doing it myself. I'd like to be able to specify the dependency in the exportAsync() method on a store. I'd love to be able to say:

    class JobConvesationStore {
        constructor() {
            this.exportAsync(source, JobStore);
        }
    

    The async method JobConversationStore would not be called until the JobStore had its data. The intent is easy to read and no complex action choreography would be needed.

提交回复
热议问题