Como lidar com relacionamentos um-para-muitos em lojas Flux

Estou apenas começando a usar o fluxo (com redux por enquanto) e estou me perguntando como os relacionamentos devem ser tratados.
Por exemplo, podemos usar o Trello que possui quadros com colunas que contêm cartões.

Uma abordagem seria ter uma loja / redutor para placas e ter todos os dados nela, mas isso significa algumas lojas muito gordas, pois elas também teriam que conter todas as ações para colunas e cartões.

Outra abordagem que vi é a separação de recursos aninhados em, por exemplo, BoardStore, ColumnStore e CardStore e usar seus IDs como referência.

Aqui está um exemplo de como estou um pouco confuso: você pode ter um criador de ações chamado addCard que solicita ao servidor que crie um cartão com todos os dados. Se você estiver fazendo uma atualização otimista, já teria criado um objeto de cartão em uma de sua loja, mas não poderá saber o ID que terá até receber a solicitação novamente.

Então, resumindo:

AddCard de queimaaddCard faz uma solicitação, enquanto isso, você retorna uma ação do tipo ADD_CARD_TEMPvocê recebe a solicitação e retorna uma ação do tipo ADD_CARD em que a loja / redutor altera o ID.

Existe uma maneira recomendada de lidar com este caso? As lojas / redutores aninhados parecem um pouco tolos para mim, mas, caso contrário, você acaba com lojas muito complexas, então parece realmente um compromisso.

questionAnswers(1)

yourAnswerToTheQuestion