Hilla und das Master-Detail-View-Pattern

René Wilby | 03.07.2025 Min. Lesezeit

Einleitung

Bei der Entwicklung von Web Apps für Unternehmen ist das Master-Detail-View-Pattern weit verbreitet.

Die Master-View enthält oft eine Liste oder ein Tabelle von Elementen, die Benutzer:innen durchblättern, sortieren und filtern können, um einen Überblick zu erhalten. Normalerweise werden die Elemente in der Master-View mit einer Teilmenge von Feldern dargestellt, um eine Überfrachtung mit Informationen oder vertikales Scrollen zu vermeiden.

Wenn die Benutzer:innen weitere Details zu einem Element benötigen, wird dieses in der Regel selektiert, und dieses Element wird in einer Detail-View angezeigt. Diese Detail-View zeigt meist alle Informationen über das Element sowie einige Aktionen, die mit diesem Element durchgeführt werden können, wie z.B. Bearbeiten, Löschen oder Drucken.

Hilla bietet verschiedene Ansätze, um das Master-Detail-View-Pattern zu implementieren, und die neue Version 24.8 hat gerade einen weiteren Ansatz hinzugefügt. In diesem Blogbeitrag werden drei bestehende Ansätze und die neue Master-Detail-Layout-Komponente, die in 24.8 eingeführt wurde, vorgestellt und vergleichen.

Beispiel-Anwendung

Um die verschiedenen Ansätze zu zeigen und zu vergleichen, wird eine einfache Beispielanwendung verwendet. Diese Anwendung bietet C.R.U.D.-Funktionen für Aufgaben. Die Aufgaben können in einer Master-View aufgelistet, sortiert und gefiltert werden und in einer Detail-View erstellt, gelesen, aktualisiert und gelöscht werden.

AutoCrud Komponente

Mit der AutoCrud-Komponente bietet Hilla einen einfachen Ansatz C.R.U.D.-Funktionen mit einem Master-Detail-View-Pattern zu implementieren.

AutoCrud Aufgaben

Master- und Detail-View sind in einer Ansicht zusammengefasst. Die AutoCrud-Komponente verwendet die Komponente AutoGrid zum Auflisten, Sortieren und Filtern aller Aufgaben und die Komponente AutoForm zum Erstellen, Lesen, Aktualisieren und Löschen einer Aufgabe. Beide Komponenten können bis zu einem gewissen Grad auf Komponentenebene angepasst werden, z. B. indem man festlegen kann, welche Spalten und Felder angezeigt werden sollen. Darüber hinaus können auch die zugrundeliegenden AutoGrid- und AutoForm-Komponenten anpasst werden, z. B. durch Angabe von benutzerdefinierten Spalten-Renderern oder durch Anpassung des Formularlayouts, das zum Rendern der Detail-View im Seitenbereich verwendet wird.

Die Breite des Seitenbereich kann von Benutzer:innen angepasst werden, und das Formular verfügt über Standard-Breakpoints, um seine Darstellung anzupassen, wenn mehr oder weniger Platz zur Verfügung steht.

AutoCrud Aufgaben-Details

Es gibt auch eine integrierte Unterstützung für mobile Geräte. Wenn man auf eine Aufgabe in der Liste tippt, wird die Detail-View in voller Bildschirmgröße angezeigt.

AutoCrud Aufgaben-Details Mobile

Die AutoCrud-Komponente bietet keinen Deep-Linking-Mechanismus für die Detail-View, d.h. man kann keinen Link wie tasks/1 teilen, der direkt auf die Detail-View der Aufgabe mit der ID 1 verweist. Ein weiterer Nachteil ist die abnehmende Benutzerfreundlichkeit, wenn man viele Informationen in der Master-View und der Detail-View anzeigen möchte, da sich beide Views den verfügbaren Platz teilen müssen und die Detail-View die Master-View schnell überlappt.

Vorteile:

  • Einfach zu implementieren

Nachteile:

  • Kein (out-of-the-box) Deep-Linking-Mechanismus für die Detail-View
  • Eingeschränkte Benutzerfreundlichkeit für komplexe Objekte (mit vielen Informationen)

Detail-Dialog

Der nächste Ansatz kombiniert ebenfalls die Master- und Detail-View in einer Ansicht. Er verwendet eine AutoGrid-Komponente, um die Aufgaben aufzulisten, zu sortieren und zu filtern, und sobald ein:e Benutzer:in auf eine Aufgabe geklickt hat, wird die Aufgabe in einer Dialog-Komponente geöffnet, die als Detail-View fungiert.

Der angezeigte Dialog ist standardmäßig modal und kann seine Größe verändern und ist verschiebbar. Die AutoForm-Komponente im Dialog behält ihr responsives Layout bei, d. h. der Dialog ist auch auf mobilen Geräten verwendbar.

Dialog Aufgaben-Details Mobile

Apropos mobile Geräte: Der Dialog kann auf drei verschiedene Arten geschlossen werden, aber nicht alle davon werden auf einem mobilen Gerät unterstützt oder sind benutzerfreundlich. Der Dialog kann folgendermaßen geschlossen werden: Durch Drücken der Esc-Taste, durch Klicken außerhalb des Dialogs oder programmatisch, zum Beispiel durch Klicken auf eine Schaltfläche.

Vorteile:

  • Einfach zu implementieren
  • Flexible Master- und Detail-Views

Nachteile:

  • Kein (out-of-the-box) Deep-Linking-Mechanismus für die Detail-View
  • Dialog-Limitierungen auf mobilen Geräten

Verwendung von Routen

Ansatz Nummer drei basiert auf zwei separaten Ansichten (oder React-Komponenten), die jeweils über einer eigenen Route erreichbar sind. Die Master-View verwendet die AutoGrid-Komponente und wird auf einer Route wie /tasks gerendert. Die Detail-View verwendet die AutoForm-Komponente und wird auf einer Route wie /tasks/{taskId} gerendert. Beide Ansichten und ihre Komponenten können den maximal verfügbaren Platz nutzen und können angepasst werden, ohne dass die andere Komponente auf derselben Seite sein muss. Dieser Ansatz unterstützt auch Deep-Linking zur Detail-View, da jede Detail-View eine URI hat.

Dieser Ansatz hat jedoch einige Nachteile. Die Navigation zwischen den beiden Ansichten muss implementiert werden. Das Laden der Aufgabe in der Detail-View anhand ihrer ID muss ebenfalls implementiert werden. Aus Sicht der Benutzerfreundlichkeit hat dieser Ansatz einen weiteren Nachteil: Die AutoGrid-Komponente in der Master-View verliert ihren Zustand, wenn die Benutzer:innen zur Detail-View navigieren, da die Komponente aus dem DOM entfernt wird. Das bedeutet, dass sich die AutoGrid-Komponente nicht an ihre aktuelle Scroll-Position, das ausgewählte Element, die aktuelle Sortierung und Filterung erinnern kann. Dies führt zu Produktivitätseinbußen, wenn Benutzer:innen viel zwischen Master- und Detail-View hin- und her-navigieren und immer wieder neu scrollen, sortieren und filtern müssen.

Vorteile:

  • Flexible Master- und Detail-Views
  • Deep-linking zur Detail-View

Nachteile:

  • Zusätzliche Implementierungen für Navigation und das Laden von Daten
  • AutoGrid in Master-View verliert ihren Zustand beim navigieren

Master-Detail Layout Komponente

Vaadin hat in Version 24.8 eine neue Master-Detail Layout-Komponente als Preview-Feature hinzugefügt. Da Vaadin Flow nicht über eine Komponente wie AutoCrud verfügt, bringt diese neue Komponente mehr Vereinfachung bei der Erstellung dieser Art von Benutzeroberflächen in Flow. Für Hilla hingegen ist der Mehrwert im Vergleich zur bestehenden AutoCrud-Komponente geringer.

Im Vergleich zu AutoCrud bietet die Master-Detail-Layout-Komponente mehr Kontrolle für Dinge wie Overlay-Breakpoints und den Stack oder Overlay-Modus. Sie unterstützt auch eine vertikale Aufteilung von Master- und Detail-View.

Wenn man die Master-Detail-Layout-Komponente so konfiguriert, dass sie den Stack-Modus verwendet, ergibt sich eine Benutzererfahrung, die dem zuvor beschriebenen Routen-basierten Ansatz sehr ähnlich ist. Die Detail-View überlagert die Master-View dabei vollständig.

Der Vorteil gegenüber dem Routen-basierten Ansatz ist, dass die Master-View nicht aus dem DOM entfernt wird, während die Detail-View angezeigt wird. Das bedeutet, dass sie ihren Zustand beibehält, wie z.B. die aktuelle Filterung und Sortierung, und die Benutzer:innen kehren zu genau diesem Zustand der Master-View zurück, wenn sie die Detail-View schließen. Leider bedeutet dies auch, dass es weiterhin keine Unterstützung für Deep-Linking zur Detail-View gibt.

Um dies zu erreichen, muss die Router-Integration der Master-Detail-Layout-Komponente verwendet werden. Dies erfordert einen gewissen zusätzlichen Aufwand, um das Router-Layout richtig einzurichten. Die Navigation und das Datenladen müssen ebenfalls implementiert werden. Der Quellcode der Beispiel-App auf GitHub enthält unter src/main/frontend/views/mdl-router-integration-tasks ein funktionierendes Beispiel für die Router-Integration mit der Master-Detail-Layout-Komponente.

Vorteile:

  • Einfach zu implementieren
  • Flexible Master- und Detail-Views mit Stack- und Overlay-Modus
  • Horizontale und vertikale Aufteilung von Master- und Detail-View

Nachteile:

  • Kein Deep-Linking zur Detail-View, außer über Router-Integration
  • Router-Integration erfordert zusätzliche Implementierungen für Navigation das Laden von Daten

Fazit

Wenn man das Master-Detail-View-Pattern in Hilla implementieren möchte, hat man die Wahl zwischen mehreren Möglichkeiten. Jeder Ansatz hat seine Vorteile, aber keiner von ihnen ist perfekt. Abhängig von den konkreten Anforderungen wird man höchstwahrscheinlich eine Lösung finden, die gut funktioniert, aber unter Umständen muss man zusätzliche Arbeit investieren, wenn man Dinge wie Deep-Linking für die Detail-View erreichen und gleichzeitig den Verlust des Zustands der Master-View vermeiden möchte.

Den Quellcode der gezeigten Beispiel-Hilla-App findet man bei GitHub.

Bildnachweis: