2016-08-02 24 views
1

Hier können zum Beispiel sagen, ich habe eine riesige Liste von Elementen, nennen wir es contacts dies 1000 Elemente in einer Liste wir Haufen von Filtern wie contact type, haben contact location, assigned to, filter ASC, Filter DESC` . Dass ein Benutzer eingeben kann, was er will. Der Speicher besteht aus redux Kontakte in einem normalisierten ObjektReagieren/Redux Abrufen und Filtern von Daten

{ 
    "1": { 
    "name": "Home Simpson", 
    "type": "Lead", 
    "location": "California", 
    "created_at": "01/01/16" 
    }, 
    "2": { 
    "name": "Ned Flanders", 
    "type": "Client", 
    "location": "SpringField", 
    "created_at": "05/01/16" 
    }, 
    [...1000+] 
} 

Nachdem alle Kontakte holen ist es besser abzubilden und alle Kontakte auf der Clientseite Filter über aus der Basis der Benutzereingabe?

Oder sollten wir eine weitere Anfrage an den Server stellen, um alle Kontakte zu den spezifischen Filtern zu erhalten?

Beachten Sie, dass nicht nur ein Parameter abgefragt werden kann, sondern mehrere Parameter. Daher contact.type ===: "Lead" || "Client", und contact.location === "Spring Field"

Was sind Best Practice für eine Abfrage dieser Größe und macht Reisen zum Server für alle passenden Kontakte wert die zusätzliche Anfrage oder ist es besser zu filter unsere redux store clientseite und nicht die last auf den server?

+0

Ich muss sagen, dass 1000 + Elemente keineswegs als groß gilt. Anfordern und Filtern auf der Client-Seite ist völlig in Ordnung. (Es sei denn, Sie zielen auf Low-Powered-Geräte) – luanped

+0

@luanped yeah Ich dachte die gleiche Sache, aber das Problem ist, einige "Benutzer" haben möglicherweise eine größere Anzahl von Kontakten sagen, zehntausend in allem hängt vom Benutzer Ich hoffe Durchschnitt wäre tausend aber Im Laufe der Zeit wird es einfach weiter wachsen und wachsen. – Enjayy

Antwort

3

In Bezug auf Redux: fühlen Sie sich frei, diese Client-Seite zu tun. Diese Art der Filterung wird sehr schnell und Redux wird es nicht verlangsamen.

Im Allgemeinen ist dies die Art von Sache, die Sie nicht optimieren möchten, es sei denn Sie tatsächlich wissen, dass es ein Problem wird. Wenn Sie über vielleicht sprechen, besteht die Gefahr, dass jemand eine Datenmenge hat, die zu viele Jahre lang zu groß ist. Dies ist eine vorschnelle Optimierung - es gibt wahrscheinlich Dutzende von Dingen, an denen Sie besser arbeiten können an Stelle von. Nach allem, was Sie wissen, könnte Nutzlast Größe ein viel größeres Problem als das sein (wie groß sind die Kontaktobjekte?)

Aber keine Notwendigkeit, jemandes Wort dafür zu nehmen. Generieren Sie einen Datensatz auf einem Zielgerät (was würde Ihr typischer Benutzer verwenden? Was ist mit dem schlimmsten Fall?), Und führen Sie Leistungsbenchmarks durch, die die Beispieldaten filtern. Ich habe das Gefühl, du wirst herausfinden, dass die Art von Filterung, die du machst, kein Flaschenhals sein wird, wenn man bedenkt, dass es nur O (n * 1) ist. Sie filtern durch n Elemente O (n) und überprüfen einen einzelnen Wert auf jedem O (1).

Auf der anderen Seite, wenn Sie eine Liste sehr komplizierter Objekte mit einem sehr komplizierten Filter haben, könnte sich das Ergebnis ändern. Wenn Sie zum Beispiel nach allen Kontakten suchen, die alle anderen Kontakte kennen, die dieselben drei spezifischen Personen kennen, wird die Komplexität steigen und Sie werden eher in einen Engpass geraten.

In jedem Fall empfehle ich Ihnen, sich selbst zu benchmarken, bevor Sie eine Menge Zeit damit verbringen, Ihre Anwendung vorzeitig zu optimieren.

+0

Danke Nathan Ich denke, du hast Recht mit den voreiligen Optimierungen Ich möchte einfach den richtigen Weg gehen anstatt das Refactor. Die Objekte sind nicht zu groß, dass es ein Problem verursachen könnte, vielleicht 20 Eigenschaften Tops und die Filter sind im Grunde Eigentum Look-Ups auf den Kontakten. Danke für den Rat, ich werde definitiv einen Benchmark aufstellen und sehen, wie es geht! – Enjayy

1

IMO, der richtige Ort, um Filter Daten nicht direkt in den Reduzierer aber in den Selektoren.

Von redux docs:

Computing Derived Data

Reselect ist eine einfache Bibliothek für memoized, zusammensetzbare Selektor Funktionen zu schaffen. Selektoren erneut auswählen können verwendet werden, um abgeleitete Daten aus dem Redux-Speicher effizient zu berechnen.

Ich verwende derzeit Selektoren zum Filtern und Sortieren von Daten.

  1. Keine Datenwiederholung im Zustand. Sie müssen keine Kopie der gefilterten Elemente auf eine bestimmte Weise speichern.
  2. Dieselben Daten können in verschiedenen Komponenten verwendet werden, wobei jede eine andere Auswahlfunktion zum Filtern verwendet.
  3. Sie können den Selektor kombinieren, indem Sie viele Datenberechnungen mithilfe des Selektors anwenden, den Sie bereits in der Anwendung haben.
  4. Wenn Sie richtig machen, werden Ihre Selektoren reine Funktionen sein, dann können Sie sie einfach testen.
  5. Verwenden Sie denselben Selektor in vielen Komponenten.