Ich lerne React und Flux und es gibt etwas, das mich an allen Beispielen stört, die ich bisher gesehen habe. Sie sind alle eine CRUD UI. In ihnen holen sie immer alle Daten nach jeder Änderung (update/add/delete etc.) Also sagen wir, wir haben eine Todo-App, und der Benutzer hat einen neuen Todo-Artikel hinzugefügt. In einer Antwort erhält der Speicher eine Aktion, ruft eine API auf dem Server auf, um das Element hinzuzufügen, und ruft dann alle Elemente erneut ab. Ist das nicht teuer? Ich verstehe, warum es Dinge vereinfacht, was gut ist. Aber warum nicht das Element zum Shop-Status hinzufügen. Ich verstehe, dass dies macht es so, dass Sie immer den Speicher halten und die Daten im Server synchronisiert, aber es ist nicht so teuer.React/Flux - alle Daten nach jedem Update abrufen/hinzufügen/entfernen
Eine Lösung, die ich sah, war Seitenumbruch, aber in dem Beispiel würden sie immer noch alle Elemente für die neue Seite erhalten, jedes Mal wenn ein Benutzer es ändert.
- Warum immer alle Daten abrufen?
- Wenn wir Paginierung verwenden - erhalten wir die neue Seite jedes Mal vom Server, wenn ein Benutzer die Seiten wechselt?
Würden Sie sagen, dass wenn ich viele Daten habe (sagen wir über 1000 Elemente), es sich lohnt, die Paginierung mit der Abfrage des Servers für jedes Update zu verwenden? Denn das Aufbewahren aller Artikel im Laden scheint ein großes Speicherproblem zu sein. Vielleicht liegt das daran, dass sie die Daten immer neu laden. – dlv
Es sollte kein Problem mit modernen Browsern sein, 10.000 Artikel im Laden zu handhaben. Paginierung ist nicht immer gut, besonders für Unternehmensanwendungen. Datagrids wie zippy-ui/react-datagrid oder ag-grid geben an, dass sie im Browser bis zu 50.000 oder gar Millionen Zeilen verarbeiten können. Für Verbraucheranwendungen ist eine Seitennumerierung sinnvoller. Die Idee ist nicht, Benutzer mit zu vielen Daten zu überfordern. Browser können 1000 Elemente sehr einfach handhaben. – vijayst
Ich sehe, danke :) – dlv