Benutzer sehen einen Teil des tief verschachtelten Status, sollten sichtbare Eigenschaften auf oberster Ebene sein?

Question

Ich arbeite an einem Spiel. Ursprünglich war der Benutzer in einem einzigen Kerker, mit den Eigenschaften:

// state 

{ 
    health: 95, 
    creatures: [ {}, {} ], 
    bigBoss: {}, 
    lightIsOn: true, 
    goldReward: 54, 
    // .. you get the idea 
} 

Nun gibt es viele Reiche und viele Dungeons, und wir können diese Daten asynchron abrufen möchten.

Ist es besser, diese tief verschachtelte Struktur im Benutzerzustand darzustellen, alle anderen möglichen Dungeons effektiv zu speichern, wenn sie geladen werden, und jedes Mal, wenn wir eine Eigenschaft aktualisieren wollen (zB Aktion TURN_ON_LIGHT), müssen wir genau finden Von welchen Dungeons reden wir oder aktualisieren die Top-Level-Eigenschaften jedes Mal, wenn wir in einen neuen Dungeon ziehen?

Der folgende Status zeigt die Verschachtelung. Die meisten der Informationen sind irrelevant für meine Präsentations-Objekte und Aktionen, sie kümmern sie nur um einen Kerker des Benutzer gerade befindet.

// state with nesting 

{ 
    health: 95, 
    kingdom: 0, 
    dungeon: 1, 
    kingdoms: [ 
    { 
     dungeons: [ 
     { 
      creatures: [ {}, {} ], 
      bigBoss: {}, 
      lightIsOn: true, 
      goldReward: 54 
     } 
     { 
      creatures: [ {}, {}, {} ], 
      bigBoss: {}, 
      lightIsOn: false, 
      goldReward: 79 
     } 
     { 
      //... 
     } 
     ] 
    } 
    { 
     // ... 
    } 
    ] 
} 

Eines der Dinge, die mich halten ist alles wieder ist, dass die saubere Reduzierung, die vorher könnte nur eine Aktion wie TURN_ON_LIGHT und aktualisieren Sie die Top-Level-Eigenschaft lightIsOn, so dass sehr geradlinige Reducer Zusammensetzung, jetzt in den Staat zu erreichen und aktualisieren Sie die richtige Eigenschaft abhängig von der kingdom und dungeon, die wir derzeit sind gibt es eine schöne Art, die Reduzierungen zu komponieren, die das sauber halten?

Answer 1

Der empfohlene Ansatz für den Umgang mit verschachtelten oder relationalen Daten in Redux ist die Normalisierung, ähnlich wie Sie eine Datenbank strukturieren würden. Verwenden Sie Objekte mit IDs als Schlüssel und die Elemente als Werte, um eine direkte Suche nach IDs zu ermöglichen, verwenden Sie Arrays von IDs, um die Reihenfolge anzugeben, und alle anderen Teile Ihres Zustands, die auf ein Element verweisen müssen, sollten nur die ID und nicht das Element selbst speichern. Dies hält Ihren Staat flacher und macht es einfacher, einen bestimmten Artikel zu aktualisieren.

Als Teil davon können Sie mehrere Ebenen von verbundenen Komponenten in Ihrer Benutzeroberfläche verwenden. Eine typische Technik bei Redux besteht darin, dass eine verbundene übergeordnete Komponente die IDs mehrerer Elemente abruft und <SomeConnectedChild itemID={itemID} /> für jede ID rendert. Dieses verbundene Kind würde dann unter Verwendung dieser ID seine eigenen Daten nachschlagen und die Daten an darunter liegende darstellende Kinder weitergeben. Aktionen, die von diesem Teilbaum ausgelöst werden, würden auf die ID des Gegenstands verweisen, und die Reduzierer wären in der Lage, den korrekten normalisierten Gegenstandseintrag darauf basierend zu aktualisieren.

Die Redux FAQ hat eine weitere Diskussion zu diesem Thema: http://redux.js.org/docs/FAQ.html#organizing-state-nested-data. Einige der Artikel über Redux-Leistung bei https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#redux-performance beschreiben den "Pass eine ID" -Ansatz, und https://medium.com/@adamrackis/querying-a-redux-store-37db8c7f3b0f ist eine gute Referenz. Schließlich gab ich nur ein Beispiel dafür, wie ein normalisierter Zustand bei https://github.com/reactjs/redux/issues/1824#issuecomment-228609501 aussehen könnte.

edit:

Als Follow-up, habe ich vor kurzem einen neuen Abschnitt zu dem Redux docs, zum Thema "Structuring Reducers". Dieser Abschnitt enthält insbesondere die Kapitel "Normalizing State Shape" und "Updating Normalized Data".