Wie man mit Eins-zu-Viele-Beziehungen in Flux-Läden umgeht

Ich fange gerade erst an, Flux (vorerst mit Redux) zu verwenden und frage mich, wie Beziehungen gehandhabt werden sollen.
Zum Beispiel können wir Trello verwenden, das Bretter mit Spalten enthält, die Karten enthalten.

Ein Ansatz wäre, einen Laden / Reduzierer für Boards zu haben und alle Daten darin zu haben, aber das bedeutet, dass einige sehr fette Läden alle Aktionen für Spalten und Karten enthalten müssten.

Ein anderer Ansatz, den ich gesehen habe, besteht darin, verschachtelte Ressourcen in BoardStore, ColumnStore und CardStore zu unterteilen und ihre IDs als Referenz zu verwenden.

Hier ist ein Beispiel dafür, wo ich ein bisschen verwirrt bin: Sie könnten einen Aktionsersteller namens addCard haben, der eine Anfrage an den Server sendet, um eine Karte mit allen Daten zu erstellen. Wenn Sie ein optimistisches Update durchführen, haben Sie zuvor in einem Geschäft ein Kartenobjekt erstellt, können jedoch die ID nicht kennen, bis Sie die Anforderung zurückerhalten.

So kurz gesagt:

Firing addCardaddCard führt eine Anfrage durch, in der Zwischenzeit geben Sie eine Aktion vom Typ ADD_CARD_TEMP @ zurü Sie erhalten die Anfrage und geben eine Aktion vom Typ ADD_CARD zurück, bei der der Store / Reducer die ID ändert.

Gibt es einen empfohlenen Weg, um mit diesem Fall umzugehen? Verschachtelte Läden / Reduzierungen sehen für mich ein bisschen albern aus, aber ansonsten hat man sehr komplexe Läden, so dass es wirklich wie ein Kompromiss aussieht.

Antworten auf die Frage(2)

Ihre Antwort auf die Frage