Staat als array von Objekten vs Objekt-sortiert nach id

Q1: Die Einfachheit der reducer ist ein Ergebnis der nicht mit der Suche durch das array zu finden, den richtigen Eintrag. Keine lästige Suche durch das array ist im Vorteil. Selektoren und andere Daten, die Zugriffsmethoden können und oft tun, Zugriff auf diese Elemente durch id. Suchen müssen durch das array für jeden Zugriff wird ein performance-Problem. Wenn Ihr arrays größer werden, das performance-Problem verschlechtert steil. Auch, wie Ihre app wird immer komplexer, anzeigen und filtern von Daten in mehr Orten, das Problem verschlimmert als gut. Die Kombination kann schädlich sein. Mit dem Zugriff auf die Elemente von id, die Zugriffszeit ändert sich von O(n) zu O(1), die für große n (hier array-Elemente) macht einen riesigen Unterschied.

Q2: Sie können normalizr helfen Ihnen bei der Konvertierung von API zu speichern. Als der normalizr V3.1.0 Sie können denormalize in die andere Richtung gehen. Das heißt, die Apps sind oft mehr Verbraucher als Produzenten von Daten und als solche der Konvertierung zu speichern, erfolgt in der Regel häufiger.

Q3: Die Fragen führen Sie in mit einem array nicht so viel Probleme mit dem Speicher-übereinkommen und/oder Inkompatibilitäten, aber mehr performance-Probleme.

1) Ist die Einfachheit der reducer die motivation für den Gang mit dem Objekt-keyed-by-id-Ansatz? Gibt es andere Vorteile, die state-Form?

Der Hauptgrund, warum Sie wollen zu halten, halten Entitäten in Objekte gespeichert und mit den IDs als Schlüssel (auch als normalisiert), ist, dass es sehr umständlich, mit zu arbeiten tief verschachtelte Objekte (das ist, was Sie erhalten in der Regel von REST-APIs in einer komplexeren app) — beide für Ihre Komponenten und Ihre Reduktionen.

Es ist ein bisschen schwer zu veranschaulichen die Vorteile einer normalisierten Zustand mit Ihrer aktuellen Beispiel (Sie nicht über eine verschachtelte Struktur). Aber lassen Sie s sagen, dass die Optionen (in deinem Beispiel) hatte auch einen Titel, und wurden von Benutzern in Ihrem system. Das würde die Antwort etwa so Aussehen statt:

[{
  id: 1,
  name: 'View',
  open: false,
  options: [
    {
      id: 10, 
      title: 'Option 10',
      created_by: { 
        id: 1, 
        username: 'thierry' 
      }
    },
    {
      id: 11, 
      title: 'Option 11',
      created_by: { 
        id: 2, 
        username: 'dennis'
      }
    },
    ...
  ],
  selectedOption: ['10'],
  parent: null,
},
...
]

Nun lassen Sie uns sagen, Sie wollten, um eine Komponente zu erstellen, die zeigt eine Liste aller Benutzer, die haben Möglichkeiten geschaffen. Das zu tun, solltest du zunächst nachfragen müssen, um alle Elemente, iteriere über jede Ihrer Möglichkeiten, und schließlich bekommen die created_by.Benutzername.

Eine bessere Lösung wäre eine Normalisierung der Reaktion, in:

results: [1],
entities: {
  filterItems: {
    1: {
      id: 1,
      name: 'View',
      open: false,
      options: [10, 11],
      selectedOption: [10],
      parent: null
    }
  },
  options: {
    10: {
      id: 10,
      title: 'Option 10',
      created_by: 1
    },
    11: {
      id: 11,
      title: 'Option 11',
      created_by: 2
    }
  },
  optionCreators: {
    1: {
      id: 1,
      username: 'thierry',
    },
    2: {
      id: 2,
      username: 'dennis'
    }
  }
}

Mit dieser Struktur, ist es viel einfacher, und effizienter, um eine Liste aller Benutzer, die haben Möglichkeiten geschaffen (wir haben Sie isoliert in Einrichtungen.optionCreators, so müssen wir nur noch eine Schleife über diese Liste).

Es ist auch ganz einfach zu zeigen, z.B. den Benutzernamen von denen, die haben Möglichkeiten geschaffen, die für das filter-Element mit ID 1:

entities
  .filterItems[1].options
  .map(id => entities.options[id])
  .map(option => entities.optionCreators[option.created_by].username)

2) Es scheint, wie das Objekt-keyed-by-id-Ansatz macht es schwieriger,
Angebot mit standard-JSON-in/out für eine API. (Das ist, warum ich ging mit der
array von Objekten in den ersten Platz.) Also, wenn Sie gehen mit diesem Ansatz
haben Sie nur eine Funktion verwenden, um es zu transformieren, hin und her zwischen JSON
format und Zustand-shape-format? Das scheint umständlich. (Obwohl, wenn du
Verfechter dieses Ansatzes, ist ein Teil Ihrer Argumentation, dass das weniger
klobig als die array-of-objects reducer oben?)

Einer JSON-Antwort kann normalisiert werden, beispielsweise mit normalizr.

3) ich weiß, Dan Abramov entwickelt redux zu theoretisch werden
state-Daten-Struktur Agnostiker (wie vorgeschlagen durch "Von der Konvention, die
top-level-Zustand ist ein Objekt oder eine andere Schlüssel-Wert-Sammlung wie ein
Karte, aber technisch kann es einen geben," Hervorhebung von mir). Aber gegeben
die oben genannten, ist es nur "empfohlen" zu halten, ein Objekt sortiert nach ID,
oder gibt es andere unvorhergesehene Schmerzen Punkte werde ich zu laufen von
mit ein array von Objekten, machen Sie es so, dass ich einfach Abbrechen
dass plan und versuchen, den Stab mit einem Objekt sortiert nach ID?

Ist es wahrscheinlich eine Empfehlung für die komplexeren apps mit vielen tief verschachtelten API-Antworten. In Ihrem speziellen Beispiel, obwohl es nicht wirklich wichtig, dass viel.