Jedes Backend-Projekt baut dieselbe Schicht erneut: Anmeldung, Layout, Tabellen, Bäume, Benachrichtigungen, Einstellungen, leere Zustände und Fehlerzustände. Danach unterscheiden sich Farben, Abstände und Interaktionsdetails, und der Aufwand für einheitliche Oberflächen wächst mit jeder Seite.
Wir haben diese Schicht zu einer wiederverwendbaren Basis zusammengefasst und unter der MIT-Lizenz veröffentlicht: admin-design, das Design und die Umsetzung eines Standard-Backends, extrahiert aus dem Frontend der Runlume-Plattform.
Was enthalten ist
- Theme und semantische Tokens: Farben laufen ausschließlich über semantische Utility-Klassen, sechs Preset-Paletten lassen sich mit Basis- und Themenfarbe kombinieren, heller und dunkler Modus folgen automatisch.
- Drei Layout-Hüllen: Seitenleiste, oben plus Seitenleiste und obere Navigation. Breite der Seitenleiste, Radius, Seitenübergänge und Reihenfolge der Kopfaktionen sind einstellbar.
- Neun Komponentenseiten: Basiselemente, Formulare und Auswahl, Datenanzeige, Rückmeldung und Overlays, Navigation und Abläufe, Kennzahlen und Diagramme, Icons, Theme und Einstellungen sowie Standardseiten. Die Übersicht ist Dokumentation und Abnahmefläche zugleich.
- Standardseitentypen: Arbeitsbereich, Liste, Detail, Einstellungen, Benachrichtigungen, Anmeldung, Registrierung und Passwort-Wiederherstellung.
- Chinesisch und Englisch von Haus aus, Tastaturbedienung und Barrierefreiheitsschalter sowie dieselbe Befehlspaletten-Suche wie in der Dokumentation.
Drei Einstiegspunkte
- Landingpage und Projektüberblick: adesign.runlume.app
- Dokumentation mit Komponentenhinweisen und Engineering-Konventionen: adoc.runlume.app
- Live-Demo mit zwei Testkonten und unterschiedlichen Rechten: ago.runlume.app
- Quellcode und Issues: github.com/runlume/admin-design
Für wen es gedacht ist und wo die Grenze liegt
Geeignet für Teams, die ihr Backend selbst bauen und die Oberfläche nicht ein zweites Mal von Grund auf schreiben wollen: Repository kopieren, Namen in package.json ändern, Menü und Markenressourcen austauschen, Beispieldaten auf die eigene API richten.
Enthalten ist nur die Design- und Interaktionsschicht: keine Geschäfts-APIs, keine Authentifizierungsimplementierung, kein Berechtigungsmodell und keine Geschäftsregeln. Beispieldaten liegen im Speicher und werden beim Neuladen zurückgesetzt. Fähigkeiten wie Identität, Uploads, Baum-Drag und Lazy Loading werden über Props injiziert; ein echter Dienst wird durch Austausch des Callbacks angebunden, nicht durch Eingriffe in die Komponente.