Aus dem Projektalltag: Evaluierung eines Data Grids

Aus dem Projekt: Evaluation von Data Grids

Avatar von Maria Haubner

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:

NameKO-KriterienMaintainedFilterSortierungCopy/PasteDrag & DropTastaturnaviStylebarLayoutbarActions pro ZeileSelektion Single/MultiEndless ScrollBesonderheiten
AG Grid
CSS & Themes
  • Kann CellRenderer und CellEditor Callbacks nutzen, um direkt React zu rendern
FancyGridscheinbar themebar
  • arbeitet u.a. auf json-Data und ist RESTful
  • alle Beispiele in der Doku sind Vanilla JS – React-Anbindung funktioniert vermutlich nur über einen Wrapper
  • React in die Edit-Ansichten zu rendern vermutlich unmöglich (nur fixes HTML möglich, keine Funktionen)
  • React in die Display-Ansichten zu rendern vermutlich möglich (Funktion auf bestehendem DOM-Element)
ParamQuery✓/✓
  • dataModel Remote könnte mit viel Mühe „von Hand“ mit GraphQL zum Laufen gebracht werden, unterstützt an sich aber nur REST
  • keine echte React-Unterstützung – wird viel Bridge-Code benötigen
  • React in die Edit-Ansichten zu rendern vermutlich möglich (Funktion auf bestehendem DOM-Element)
  • React in die Display-Ansichten zu rendern vermutlich sehr schwierig (Funktion wird ausgeführt, gibt aber nur einen String zurück)
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.

Avatar von Maria Haubner

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.