estou a usaralt como minha implementação de fluxo para um projeto e estou tendo problemas para entender a melhor maneira de lidar com o carregamento de lojas para duas entidades relacionadas. estou a usarfontes , juntamente com registerAsync, para manipular minhas chamadas async / api e vinculá-las às minhas visualizações usando o AltContainer.

Eu tenho duas entidades relacionadas uma a uma pelo conversionId. Ambos são carregados através de uma chamada API:

Depois que minha loja de trabalho estiver carregada com dados, desejo preencher uma loja de conversação.

Eu uso uma fonte para carregar o repositório de trabalhos:

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

            },....

Parece um trabalho para oEsperar por() , mas parece ser usado quando o conteúdo de uma loja exige uma transformação ou mesclagem com o conteúdo de outra. Preciso buscar o conteúdo de um armazenamento de dados com base no conteúdo de outro.

Em termos gerais, eu preciso:

Ligue para uma API de terceiros e carregue uma lista de entidades em uma loja.Quando esses dados chegam, preciso usar o atributo de cada uma das opções acima para chamar outra API e carregar esses dados em outro armazenamento.

Minha solução ingênua é referenciar as ações de conversa do armazenamento de tarefas e despachar um evento quando os dados chegarem. Algo assim:

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);
    }
}

Obviamente, fazer isso viola o ditado de que as lojas não devem despachar eventos e, portanto, devo usar o adiamento para despachar uma ação no meio de uma expedição. Faz sentido para mim, já que, ao seguir esse caminho, estou reintroduzindo todos os tipos de efeitos colaterais no meu código; perdendo a beleza dos "gasodutos funcionais" que eu deveria estar vendo com fluxo.

Além disso, meu repositório de tarefas deve conter uma referência a quaisquer entidades dependentes para que ele possa despachar a ação apropriada. Aqui eu tenho apenas um, mas eu poderia imaginar muitos. Em termos das dependências entre entidades, isso parece totalmente ao contrário.

Algumas alternativas vêm à mente:

Eu posso ligar para oAPI / plataforma / empregos ponto final na origem / ação em que busco todas as conversas, apenas para obter o ID. A abordagem original é mais eficiente, mas isso parece mais fiel ao espírito do fluxo, pois eu perco toda a conversa cruzada.

Eu também poderia ter uma única ação / fonte que busca ambos, retornando{jobs:{}, conversations: in the action} (orquestrando a dependência usando promessas) e use isso para preencher as duas lojas. Mas essa abordagem parece desnecessariamente complicada para mim (acho que não deveria ter que fazer isso!).

Mas estou perdendo outro caminho? Parece estranho que um caso de uso tão comum quebre a elegância do paradigma do fluxo e / ou me force a saltar por tantos obstáculos.

@dougajmcdonald fez uma pergunta semelhanteaqui, mas talvez tenha sido formulado de maneira muito geral e não tenha tração: