ag-grid-community: Unendliches Zeilenmodell für serverseitige Paginierung, kostenlose Community-Version agGrid - Funktioniert nicht wie serverseitige Paginierung
Ich habe genug Zeit damit verbracht, dies zu verstehen und umzusetzen, aber anscheinend ist die Dokumentation entweder nicht sehr klar geschrieben oder ich verstehe einige grundlegende Dinge nicht.
Mit ag-grid-community 22.1.1 kann nicht viel Backend-Code geändert werden, sodass Vorschläge für Änderungen im Backend nicht funktionieren. Die beste Option, die ich sehen konnte, ist das Modell mit unendlichen Zeilen, wie sie erklärt haben. offizielle Dokumentation von ag-grid

Wie im obigen Bild dargestellt, gibt meine Backend-API langsame Antworten zurück, wenn sie langsam ist und Daten langsam zurückgibt, was mir nicht viel helfen kann, da sie wiederum eine externe API außerhalb meines Steuerelements aufruft.
- Grid ruft die Backend-API auf, die in 200 Sekunden 500 Datensätze zurückgibt.
- Der Benutzer muss mehr als 3 Minuten warten, um alle Daten auf dem Bildschirm anzuzeigen.
- Basierend auf dem unendlichen Zeilenmodell dachte ich nach der Implementierung, wenn
cacheBlockSize
es 50 ist, könnte ich den Server bitten, 50 Datensätze zu senden, und die Antwort, um die Daten im Raster zu sehen, wird schneller sein und wenn ich als nächstes klicke, werden die nächsten 50 abgerufen und die Zeit für jeden Block würde 20 Sekunden sein . - Aber es funktioniert nicht so, der http-Aufruf des Backends wartet darauf, dass alle Datensätze zurückkommen, und dann beginnt nur das Rendern des Rasters und zeigt ein Ergebnis an. Sie müssen also noch 200 Sekunden warten, um Daten anzuzeigen. Was bringt es also, dieses unendliche Scrollen als serverseitig zu bezeichnen?
- Außerdem ist meine Implementierung korrekt, da ich sehen konnte, wie sich der Cursor in Chrome Dev Tools zum ersten Mal von 0-50 und dann von 50-100 bewegt
Antworten
Sie haben geschrieben, dass Sie nicht viel Backend-Code ändern können, daher bin ich mir nicht sicher, ob Sie so etwas tun können, aber Sie müssen mindestens ein datasource
Objekt mit einem definieren getRows()
. Dieser Rückruf wird jedes Mal aufgerufen, wenn das Grid versucht, neue Zeilen vom Server abzurufen, und es werden die hier angezeigten Parameter verwendet .
Wenn dieser Rückruf ausgelöst wird, müssen Sie Ihre Promise
Funktion aufrufen , die Ihre Daten mit dem params.startRow
Parameter abruft , und entweder die params.endRow
oder cacheBlockSize
die 50, wie Sie sagen.
Wenn der Abruf erfolgreich ist, rufen Sie an successCallback(rowsRetrievedOnThisFetch, lastRow)
, wo lastRow
sich der Index der letzten Zeile Ihrer Daten befindet, wenn sich alle Ihre Daten im Raster befinden . Wenn nicht alle Daten im Raster vorhanden ist, stellen die lastRow
gleich undefined
, null
oder -1
.
Wenn später alle 500 Zeilen geladen sind, können Sie festlegen lastRow = 500
und aufrufen successCallback(rowsRetrievedOnThisFetch, 500)
.
Dies funktioniert, wenn Sie Daten in Blöcken und nicht alle gleichzeitig abrufen können. Jedes Mal, wenn Sie die Abruffunktion aufrufen, müssen Sie den Zeilenbereich angeben, den Sie aus der Datenbank abrufen möchten. Sie können dies jedoch nur tun, wenn Ihre API dies unterstützt.
Wenn Sie das Modell mit unendlichen Zeilen verwenden, filtert oder sortiert das Raster die Zeilen nicht selbstständig. Sie werden passieren müssen params.filterModel
und params.sortModel
jeweils in der Abfrage , wenn getRows()
Feuer , wenn Sie serverseitige Filterung und Sortierung verwendet werden sollen.
AKTUALISIEREN
Schauen Sie sich dieses Beispiel an: https://plnkr.co/edit/pqBAS1cnjKiBoqeQ. Es werden 500 Zeilen in Stapeln von 50 geladen. Jedes Mal, wenn Sie nach unten scrollen, werden die nächsten 50 Zeilen geladen, bis alle 500 Zeilen im Raster sind.