Redux Datenstrukturierung

Question

Ich versuche, eine komplexe voll dynamische App mit Redux zu erstellen. Ich meine, meine App hat viele dynamisch generierte Formulare mit generierten Feldern - Komponenten on-the-fly. Ich möchte in meinem Redux-Shop auch visuelle Daten über meine Komponenten speichern. Aber wie soll ich das machen, ohne reale Daten mit visuellen Komponentendaten zu mischen?

Zum Beispiel, wenn ich Struktur wie diese

Store { 
    visual: {...deeply nested visual-data-tree...}, 
    data: {...deeply-nested real-data-tree...} 
} 

Es ist schwer Komponente zu machen, weil ich erste visuelle Daten suchen müssen, dann Komponente „Wert“ in zwei Bäume reagieren.

Aber wenn eine ähnliche Struktur wie diese haben:

Store { 
    form { 
    visual: {...form visual data...}, 
    data: { 
     //Ok here the form "data" - widgets. Or it must to be visual? :) 
     widget1 { 
     visual: {type:"ComboBox", opened: true}, 
     data: 1 
     } 
    } 
    } 
} 

Sie sehen das Problem, jetzt habe ich visuelle Daten in realen Daten von Form-Widget.

(Form - Daten - Bedienelement1 - visuelle)

Visuelle Daten innerhalb der realen Daten aus dem Konzept.

Wie lösen Sie die gleichen Probleme beim Mischen von Daten?

Tut mir wirklich leid für mein schlechtes Englisch. Ich hoffe, ich habe das Problem klar erklärt.

Answer 1

Ist die Unterscheidung nicht oberflächlich? Ich denke, eine wichtigere Regel ist, dass die Daten im Zustand normalisiert werden sollten. Zum Beispiel, wenn Sie Combobox Widget haben lassen Sie wählen Benutzer, Ihre Daten besser

{ 
    chosenUserId: 10, // Good! 
    users: { 
    10: { name: 'Alice' } 
} 

statt

{ 
    chosenUser: { name: 'Alice' }, // Bad! 
    users: { 
    10: { name: 'Alice' } 
} 

sein formen Wenn die Daten in dem Zustandsbaum dupliziert wird, ist es schwer, es richtig zu aktualisieren und vermeiden Sie Inkonsistenzen.

Solange Sie die Daten normalisiert halten, sehe ich keine echte Notwendigkeit zu teilen visual und data. Möglicherweise möchten Sie den Entitätscache auf oberster Ebene haben, der wie eine Datenbank aussieht (z. B. entities, einschließlich users, posts oder andere Datenobjekte, die in Ihrer App verwendet werden). Ansonsten sollten Sie die Statusform verwenden, die am bequemsten ist Zustand.