Datei-Baum-Explorer-UI mit Tailwind CSS: rekursive Ordnerstruktur bauen

1. Warum ein Datei-Baum eine eigene Denkweise braucht

Anders als eine flache Liste oder ein einfaches Grid muss ein Datei-Baum eine Struktur abbilden, deren Tiefe zur Laufzeit nicht feststeht: Ein Ordner kann leer sein, fünf Dateien enthalten oder selbst wieder zehn Unterordner mit jeweils eigenen Unterordnern verschachteln. Diese unbekannte Tiefe lässt sich in HTML nicht mit einer festen Anzahl verschachtelter div-Elemente lösen, sondern verlangt eine rekursive Komponente, die sich selbst mit den Kindern eines Ordners erneut aufruft, bis keine weiteren Unterordner mehr übrig sind.

Zusätzlich zur reinen Struktur kommen mehrere interaktive Anforderungen hinzu, die in einem klassischen Datei-Explorer-Fenster selbstverständlich sind, im Browser aber jeweils explizit gebaut werden müssen: ein Auf- und Zuklappen einzelner Ordner mit visueller Rückmeldung, eine klare Unterscheidung der Dateitypen auf einen Blick, eine Markierung des aktuell ausgewählten Eintrags sowie eine Hervorhebung des Zielordners, während eine Datei per Drag-and-Drop darüber gezogen wird. Tailwind liefert dafür die Utility-Klassen, Alpine.js übernimmt die Zustandslogik pro Knoten.

2. Die rekursive Baum-Komponente mit Alpine

Der Kern des Musters ist eine Alpine-Komponente, die sich selbst über ein template-Tag mit x-if und einen darin eingebetteten Aufruf ihrer selbst rekursiv referenziert. Jeder Knoten bekommt sein eigenes x-data mit einem Boolean für den Auf-/Zuklapp-Zustand, sodass jeder Ordner unabhängig von seinen Geschwistern und seinem Elternknoten geöffnet oder geschlossen werden kann. Die Kinder eines Ordners werden nur gerendert, wenn der Ordner selbst geöffnet ist, damit bei einem großen Baum nicht sofort die komplette Struktur im DOM landet.

Wichtig ist, dass die rekursive Komponente als wiederverwendbares Alpine-Template über x-if in ein template-Element eingebettet und per Alpine-Komponente registriert wird, statt versucht wird, ein Web Component oder eine serverseitige Template-Engine rekursiv aufzurufen. Das hält die gesamte Logik in einer einzigen Datei und macht den Baum unabhängig davon, wie viele Ebenen tatsächlich vorhanden sind, ohne dass für jede mögliche Tiefe eine eigene Vorlage existieren müsste.

<template x-if="true">
  <ul class="space-y-0.5" :style="`padding-left: ${depth * 1}rem`">
    <template x-for="node in nodes" :key="node.id">
      <li>
        <div
          class="group flex items-center gap-1.5 rounded px-1.5 py-1 text-sm hover:bg-slate-100"
          :class="node.id === selectedId && 'bg-blue-50 text-blue-700'"
          @click="node.type === 'file' ? select(node.id) : toggle(node)"
        >
          <svg
            x-show="node.type === 'folder'"
            class="h-3.5 w-3.5 shrink-0 transition-transform duration-150"
            :class="node.open && 'rotate-90'"
          ><!-- Chevron --></svg>

          <span x-text="fileIcon(node)" class="w-4 shrink-0 text-center"></span>
          <span x-text="node.name" class="truncate"></span>
        </div>

        <template x-if="node.type === 'folder' && node.open">
          <div x-html="renderChildren(node.children, depth + 1)"></div>
        </template>
      </li>
    </template>
  </ul>
</template>

3. Einrückung pro Verschachtelungstiefe

Die Einrückung muss proportional zur Tiefe im Baum wachsen, damit die Hierarchie auf den ersten Blick erkennbar bleibt, ohne bei sehr tiefen Strukturen den verfügbaren horizontalen Platz komplett aufzubrauchen. Praktisch bewährt sich ein Wert zwischen 0,875rem und 1,25rem pro Ebene, berechnet über ein Inline-Style mit der aktuellen Tiefe als Alpine-Variable, da Tailwinds statische Utility-Klassen keine dynamische Multiplikation mit einer zur Laufzeit unbekannten Zahl abbilden können.

Für sehr tiefe Bäume, etwa jenseits von acht oder neun Ebenen, lohnt sich eine Deckelung der maximalen Einrückung, damit tief verschachtelte Einträge nicht komplett aus dem sichtbaren Bereich herauswandern. Eine zusätzliche vertikale Leitlinie, realisiert über einen linken Rand am umschließenden Container jeder Ebene, hilft zusätzlich dabei, zusammengehörige Einträge auch bei größerer Tiefe optisch zu gruppieren, ohne dass die Einrückung allein die komplette Orientierungsarbeit übernehmen muss.

4. Auf-/Zuklapp-Icons mit Rotation-Transition

Ein einzelnes Chevron-Icon pro Ordner reicht aus, um sowohl den geschlossenen als auch den geöffneten Zustand darzustellen, solange es sich beim Öffnen sichtbar dreht. Mit transition-transform und einer bedingten rotate-90-Klasse lässt sich das ohne zwei separate Icon-Sets umsetzen: Im geschlossenen Zustand zeigt das Chevron nach rechts, im geöffneten Zustand nach unten, angedeutet durch eine Rotation um 90 Grad. Die Transition-Dauer sollte kurz bleiben, etwa 150 Millisekunden, da Nutzerinnen beim schnellen Durchklicken vieler Ordner sonst auf die Animation warten müssten.

Ordner ohne Kinder sollten kein Chevron zeigen, sonst wirkt die Struktur inkonsistent, wenn ein Klick auf ein scheinbar aufklappbares Icon nichts bewirkt. Am saubersten lässt sich das über eine bedingte Sichtbarkeit lösen, die prüft, ob das Kinder-Array des Knotens leer ist, statt das Icon einfach ausgegraut, aber weiterhin klickbar darzustellen.

5. Dateityp-abhängige Icons

Damit Nutzerinnen den Dateityp erkennen, ohne den Dateinamen bis zur Endung lesen zu müssen, bekommt jeder Datei-Eintrag ein Icon, das von der Dateiendung abhängt. Praktisch wird das über eine Zuordnungstabelle in JavaScript gelöst, die gängige Endungen wie .js, .css, .md oder .png auf ein passendes Icon oder eine Icon-Farbe abbildet, mit einem generischen Icon als Fallback für unbekannte Endungen, damit nie ein leerer Platzhalter entsteht.

Farblich lohnt sich eine begrenzte Palette statt einer für jeden Dateityp individuellen Farbe, etwa Gelb für Konfigurationsdateien, Blau für Code-Dateien und Grau für Textdateien, damit die Übersicht bei vielen unterschiedlichen Endungen nicht in ein visuelles Durcheinander kippt. Ordner-Icons sollten sich davon klar farblich absetzen, meist über einen dezenten Gelbton, damit die Grundunterscheidung zwischen Ordner und Datei auch bei flüchtigem Blick sofort klar ist.

6. Auswahl-Highlight für den aktiven Eintrag

Ein ausgewählter Eintrag braucht eine deutlich sichtbare, aber nicht aufdringliche Hervorhebung, da der Baum oft neben einem Vorschaubereich steht, der den Inhalt der ausgewählten Datei anzeigt. Eine helle Hintergrundfarbe kombiniert mit einer dunkleren Textfarbe für Icon und Namen funktioniert zuverlässig, wichtig ist dabei, dass die ID des ausgewählten Knotens zentral in einem gemeinsamen Alpine-Store oder einer übergeordneten Komponente gehalten wird, statt in jedem einzelnen Knoten redundant gespeichert zu werden.

Bei Mehrfachauswahl, etwa mit gedrückter Strg- oder Shift-Taste, wächst die Komplexität deutlich, da nun eine Menge von IDs statt einer einzelnen ID verwaltet werden muss und die Shift-Auswahl den zuletzt angeklickten Bereich innerhalb der sichtbaren, aktuell aufgeklappten Reihenfolge berücksichtigen muss. Für die meisten Anwendungsfälle reicht jedoch eine Einzelauswahl, Mehrfachauswahl lohnt sich erst, wenn tatsächlich Aktionen wie Verschieben oder Löschen auf mehrere Dateien gleichzeitig angewendet werden sollen.

7. Drag-Ziel-Hervorhebung beim Verschieben

Beim Verschieben einer Datei per Drag-and-Drop muss der Zielordner, über dem die gezogene Datei gerade schwebt, klar erkennbar hervorgehoben werden, damit die Nutzerin sicher sein kann, in welchem Ordner die Datei landen würde, wenn sie jetzt losließe. Die nativen HTML5-Drag-Events dragover und dragleave lassen sich direkt mit Alpine verdrahten, wobei dragover zwingend preventDefault() aufrufen muss, da der Browser einen Drop sonst grundsätzlich verweigert.

Optisch reicht ein deutlicher Rahmen in einer Akzentfarbe kombiniert mit einer leicht abweichenden Hintergrundfarbe für das aktuelle Drop-Ziel. Ein häufiger Fehler ist, dass dragleave auch dann ausgelöst wird, wenn die Maus lediglich über ein Kind-Element innerhalb desselben Ordners wandert, was das Highlight unerwünscht flackern lässt. Abhilfe schafft ein Zähler, der bei jedem dragenter erhöht und bei jedem dragleave verringert wird, damit das Highlight erst bei einem Zählerstand von null tatsächlich entfernt wird.

<div
  x-data="{ dragCount: 0 }"
  @dragenter.prevent="dragCount++"
  @dragleave.prevent="dragCount--"
  @dragover.prevent
  @drop.prevent="dragCount = 0; moveInto(node.id)"
  class="rounded px-1.5 py-1"
  :class="dragCount > 0 && 'bg-blue-100 ring-1 ring-blue-400'"
>
  <span x-text="node.name"></span>
</div>

8. Performance bei sehr großen Baumstrukturen

Bei mehreren tausend Dateien und Ordnern wird das naive Rendern des kompletten Baums, selbst mit eingeklappten Unterordnern, spürbar langsam, weil Alpine für jeden Knoten reaktive Beobachter einrichten muss, sobald er im DOM existiert. Eine erste Verbesserung ist, Kinder eines Ordners tatsächlich erst beim ersten Öffnen aus dem DOM zu entfernen beziehungsweise gar nicht erst zu rendern, statt sie nur über CSS zu verstecken, denn ausgeblendete, aber weiterhin vorhandene Elemente kosten weiterhin Speicher und Rechenzeit.

Für wirklich große Strukturen, etwa ein komplettes Projektverzeichnis mit zehntausenden Dateien, reicht clientseitiges Rendering irgendwann nicht mehr aus, unabhängig davon, wie sparsam die DOM-Knoten gehalten werden. Hier lohnt sich entweder eine serverseitige Paginierung pro Ordnerebene oder eine echte Virtualisierung der sichtbaren Zeilen, bei der nur die aktuell im Viewport sichtbaren Einträge tatsächlich im DOM existieren und der Rest beim Scrollen dynamisch nachgeladen wird.

9. Grenzen des Musters und typische Stolperfallen

Eine häufige Stolperfalle ist zirkuläre oder extrem tiefe Verschachtelung in den Eingabedaten, etwa durch einen fehlerhaften symbolischen Link, der auf sich selbst oder einen übergeordneten Ordner verweist. Ohne eine Tiefenbegrenzung in der rekursiven Komponente kann das zu einer Endlosschleife im Rendering führen, die den Browser-Tab komplett einfriert. Eine einfache maximale Rekursionstiefe als Sicherheitsnetz, mit einer Warnung statt eines weiteren Rekursionsaufrufs bei Überschreitung, verhindert dieses Szenario zuverlässig.

Eine zweite Grenze betrifft die Drag-and-Drop-Interaktion auf Touch-Geräten: Die nativen HTML5-Drag-Events funktionieren auf den meisten mobilen Browsern nicht zuverlässig, weshalb ein Datei-Baum, der auch auf Tablets bedienbar sein soll, zusätzlich eine touch-basierte Alternative braucht, etwa über Pointer-Events oder eine explizite Verschieben-Aktion im Kontextmenü statt reinem Ziehen. Wer nur Desktop-Nutzung erwartet, kann auf diese Zusatzarbeit verzichten, sollte das aber bewusst als Einschränkung dokumentieren.

10. Zusammenfassung

11. FAQ: Datei-Baum-Explorer mit Tailwind: Das Wichtigste auf einen Blick