4 Punkte von GN⁺ 2024-01-01 | 1 Kommentare | Auf WhatsApp teilen

Gefälschte Bäume: Eine einfache UI mit Einrückungen

  • Wenn man in einer UI eine Liste in Baumform haben möchte, erfordert die Umsetzung von Eltern-Kind-Beziehungen viel Arbeit und komplexe Datenstrukturen.
  • In relationalen Datenbanken lassen sich Baumstrukturdaten mit rekursiven CTEs (Common Table Expressions) abrufen.

Muss die Datenstruktur wirklich ein Baum sein?

  • Man sollte überlegen, ob die Elemente tatsächlich eine Eltern-Kind-Beziehung haben müssen oder nur so aussehen sollen.
  • Wenn keine echte Beziehung nötig ist, lässt sich ein Baum einfach mit den Feldern id, sort, indent und name speichern.
  • Da dieser Ansatz genau das abbildet, was auf dem Bildschirm zu sehen ist, wird es deutlich einfacher, eine Oberfläche zum Rendern und Bearbeiten der Liste zu erstellen.

Ein weiteres Beispiel mit „Namespacing“

  • In HissScript wird die Namespacing-Funktion umgesetzt, indem beim Vorhandensein eines Punkts (.) im Elementnamen der erste Teil abgeschnitten und das Element eingerückt wird.
  • Für Spiel-Editoren und Player ist Namespacing wichtig, tatsächlich handelt es sich aber nur um einfache Namen.
  • Oft brauchen Menschen nicht die echte Baumstruktur, sondern nur ihr Erscheinungsbild.

Bonus: Baum-Liste

  • In Nachahmung echter Bäume werden Pfade und Informationen in einer flachen Liste gespeichert; für Tiefensuche oder Breitensuche werden die Pfade entsprechend sortiert.
  • Mit flachen Listen lässt sich im Allgemeinen leichter arbeiten, und sie passen gut zu Computern.

Physische Analogie

  • Beim Organisieren eines persönlichen Scrapbooks ist für Menschen klar, wie Gruppen funktionieren, aber auf dem Boden gibt es in Wirklichkeit keinen physikalischen Mechanismus, der solche Beziehungen erzwingt.

Achtung: Es gibt keine Lösung für alle Situationen

  • Techniken sollten passend zum jeweiligen Szenario eingesetzt werden; wenn eine echte Baumstruktur nötig ist, sollte man auch einen Baum verwenden.
  • Wenn man die tatsächlichen Beziehungen zwischen Elementen kennen muss, sollte man keine Hacks wie Einrückungen oder das Zählen von Symbolen in Zeichenketten verwenden.

GN⁺-Meinung:

  • Dieser Artikel zeigt, wie sich Benutzeroberflächen vereinfachen lassen, indem man statt komplexer Baumstrukturen visuell einfache Einrückungen verwendet.
  • Für Entwickler ist das eine effektive Strategie, um Datenstrukturen zu vereinfachen, Entwicklungszeit zu sparen und die Wartung zu erleichtern.
  • Der Artikel betont, dass eine Baumstruktur nicht immer notwendig ist und manchmal schon eine für Nutzer vertraute visuelle Struktur ausreicht, und eröffnet Entwicklern damit eine neue Perspektive zur Verbesserung der User Experience.

1 Kommentare

 
GN⁺ 2024-01-01
Hacker-News-Kommentar
  • Der erste Ansatz, die „Adjacency List“, gilt als die „offensichtlich einzig richtige Methode“.

  • Der zweite Ansatz ist ein „viel einfacherer Weg“, den man zuvor noch nie gesehen hat; er hat offensichtliche Schwächen, ist in manchen Fällen aber ausreichend klar.

  • Die dritte Methode, „Namespacing“, wird als „materialized path“ bezeichnet.

  • Eine weitere Möglichkeit, Bäume darzustellen, sind „nested sets“, ein Verfahren, das aus der Zeit bekannt ist, als relationale Datenbanken sehr ernsthaft behandelt wurden.

  • Postgres bietet den Datentyp ltree und Suchoperatoren dafür an, womit sich Baumstrukturen auf natürliche Weise behandeln lassen. Man kann zum Beispiel mit ltree eine Tabelle anlegen, Daten einfügen und dann mit einfachen Abfragen die Baumstruktur durchsuchen.

  • Die Werte innerhalb einer Struktur sind oft eher eine Datenhierarchie als ein angezeigter Baum. Man möchte die Daten vielleicht traversieren, Beziehungen darstellen oder umsortieren. Visuelle Informationen in der Datenstruktur innerhalb der Datenbank zu speichern, kann kurzsichtig wirken.

  • Es gibt Erfahrung mit der Gründung eines Unternehmens, das mit baumförmigen Daten gearbeitet hat. Es ist möglich, eine Baumstruktur in O(n)-Zeit in eine eingerückte Liste umzuwandeln. Das war eine der Interviewfragen, und in SQL-Datenbanken gibt es verschiedene Möglichkeiten, Teile eines Baums schnell zu holen und zu rendern, auch ohne rekursive Abfragen.

  • Eine Möglichkeit, mit SQL-Abfragen Baumdaten aus einer relationalen Datenbank zu holen, ist das Schreiben rekursiver CTEs (Common Table Expressions). CTEs machen tatsächlich Spaß, und sobald man sich daran gewöhnt hat, muss man keine Angst mehr davor haben.

  • Aus Erfahrung lernt man, dass Menschen oft gar keinen echten Baum wollen, sondern nur das Aussehen eines Baums brauchen. HN und Reddit unterscheiden sich darin. Bei HN ist ein Kindkommentar das nächste Geschwisterelement des Elternkommentars, und die Einrückung wird gegenüber der des Elternkommentars um eins erhöht, um die Baumoptik nachzuahmen. Bei Reddit dagegen sind Kindkommentare tatsächlich innerhalb des Elternkommentars verschachtelt.

  • Die Kernidee des Artikels ist, eine zur Aufgabe passende Struktur zu verwenden. Der Aufbau der Argumentation ist jedoch fehlerhaft. Man braucht keine CTEs, um Bäume aus einer Datenbank zu laden, sondern kann eine flache Liste holen und den Baum lokal zusammensetzen. Bei ausreichend großen Bäumen können außerdem lineare Kosten entstehen, wenn man Äste verschieben oder die Tiefe ändern möchte.

  • Beim Beschreiben von Taxonomien oder anderen Hierarchien wurde ein einfacher und schneller Weg mit dem lokalen Dateisystem gelernt. Mit den Befehlen mkdir und tree lässt sich etwas erzeugen, das man in E-Mails, Slack, Pastebins usw. einfügen und weitergeben kann.

  • Wenn man nur speichern und laden möchte, kann es eine einfachere Lösung sein, die Daten in der gewünschten Form zu serialisieren, etwa als JSON, und als String zu speichern. Die Verwendung der Punktnotation ähnelt der Art, wie die VSCode-Erweiterung Dendron mit Namenshierarchien umgeht.

  • Vor einigen Jahren gab es eine ähnliche Erkenntnis bei OpenGL: Man muss keine Welt aus hierarchischen 3D-Objekten rendern, sondern nur eine sortierte Liste von Dreiecken. Das macht viele Optimierungen sehr einfach.