Die Darstellung und Bearbeitung von Daten in einer Web-App lässt sich häufig am besten über Tabellen lösen.
Tabellen sind für die User bekannte Konzepte und in der Regel finden sie sich deswegen schnell zurecht. Doch gleichzeitig haben sie bestimmte Erwartungen, was in Tabellen möglich sein sollte – schließlich bieten Tabellenbearbeitungsprogramme wie Excel oder LibreOffice einen massiven Funktionsumfang.
Und wäre es nicht schön und komfortabel, diese Funktionalitäten auch in einer Web-App zu haben?
Die Herausforderung
Es kann allerdings sehr schwierig sein, bestimmte Funktionalitäten einzubauen …
Nehmen wir zum Beispiel das Filtern und Sortieren von Daten: Wenn die Datensätze sehr groß sind, will man sie in einer Web-App eher nur partiell laden. Also beispielsweise nur die Datensätze, die der User in dem Moment auch gerade sehen kann. Scrollt der User dann durch die Liste, sollen die anderen Datensätze nachgeladen werden.
Doch das bedeutet, dass Sortierung und Filterung keine Operationen im Browser-Cache sind, da dieser nicht den kompletten Datensatz beinhaltet – sondern es sind Queries an den Server, die wiederum also zu neuen Ladezeiten führen.
Oder man will die Datensätze umsortieren, zum Beispiel per Drag & Drop von Tabellenzeilen. Natürlich gibt es Bibliotheken da draußen, die die UI-Darstellung lösen. Auf der Datenbankseite kann das aber schon wieder komplizierter werden, vor allem wenn man nicht will, dass sich alle betroffenen Datensätze verändern, sondern nur der eine Verschobene seine Position im Datensatz ändert.
In unserer React/TypeScript/GraphQL-Anwendung haben wir nun entschlossen, Data Grids zu evaluieren. Anstatt zig neue Abhängigkeiten in unsere Anwendung zu integrieren die aktualisiert und gepflegt werden wollen – und in der Regel nur einen oder wenige neue Use Cases bedienen – schauen wir, ob es nicht eine „eierlegende Wollmilchsau“ gibt, die vielleicht alles kann, was wir brauchen – und mehr. Ich möchte hier kurz erzählen, wie wir an die Evaluierung herangehen.
Data Grids – die Optionen
Der Anfangspunkt für uns war die Seite jsgrids.statico.io.
Diese Seite vergleicht und sortiert SpreadSheet- und Data-Grid-Bibliotheken und gibt umfangreiche Möglichkeiten, um diejenigen herauszufiltern, die für uns interessant sind.
Man kann auswählen, in welchem Framework sie laufen sollen (Angular, Vue, oder in unserem Fall React) und welche Features wichtig sind. Außerdem kann man nach der Lizenzart und der Beliebtheit filtern.
Der nächste Schritt für uns war also, eine erste Liste zu erstellen, welche Features für uns wichtig sind. Unsere Liste sieht so aus:
- Filterbar
- Sortierbar
- Copy & Paste
- Drag & Drop
- Navigierbar mit Tastatur
- Stylebar
- Container/Layout FullHeight vs fixed
- Actions pro Zeile
- Single & Multi Select
- Endless Scroll
Wir hatten auch weitere Anforderungen. Die Bibliothek sollte aktiv maintained sein, in die Zellen und Filter sollten wenn möglich eigene React-Komponenten integrierbar sein, die dahinter liegende Datenstruktur war uns wichtig und einige mehr.
Wir haben also die Features soweit wie möglich in jsgrids.statico.io eingegeben und sind bei folgenden vier Data Grids gelandet:
- ag-Grid
- FancyGrid
- ParamQuery
- jqGrid
Dokus und Demos wälzen
Mit dieser Auswahl sind wir losgezogen und haben uns Dokus und Demos angeschaut, um einen groben Überblick zu bekommen und einen Favoriten zu identifizieren. Dazu haben wir die Features mit denen verglichen, die wir wie weiter oben beschrieben als „wichtig“ definiert haben. Herausgekommen ist eine Matrix, die so aussieht:
Name | KO-Kriterien | Maintained | Filter | Sortierung | Copy/Paste | Drag & Drop | Tastaturnavi | Stylebar | Layoutbar | Actions pro Zeile | Selektion Single/Multi | Endless Scroll | Besonderheiten |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
AG Grid | – | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ CSS & Themes | ✓ | ✓ | ✓ |
| |
FancyGrid | – | ✓ | ✓ | ✓ | ❓ | ✓ | ✓ | scheinbar themebar | ✓ | ✓ | ✓ |
| |
ParamQuery | – | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓/✓ | ✗ |
|
jqGrid | – | ✓ | ✓ (sehr hässlich) | ✓ | ✗ | ✗ Demo für „between grids“, aber nicht innerhalb eines Grids? | ✗ nur Zeilenweise, kollidiert mit Edit | ✓ | ✓ | ✓/✗ | ✓ | – |
And the winner is …
Nach dieser groben Evaluation haben wir festgestellt, dass wir uns als ersten Kandidaten ag-Grid genauer anschauen. Das heißt, dass wir hier jetzt in den Code gehen und „die Innereien“ untersuchen.
Danach wissen wir dann hoffentlich, ob Data Grids für uns eine valide Alternative zur Eigenentwicklung von feature-reichen Tabellen sind.
Schreibe einen Kommentar