React v19 - shadcn/ui

React v19+ — shadcn/ui

0:00 Der Umgang mit fremdem Code folgt seit Jahren einer festen Regel: Man installiert ein Paket, bindet es ein und fasst es nicht an. Was drin ist, geht einen nichts an — bis man doch etwas ändern muss und feststellt, dass die eine Einstellung, die man bräuchte, nicht vorgesehen ist. shadcn/ui bricht mit dieser Regel auf eine Weise, die zunächst rückständig wirkt: Die Komponenten werden in Ihr Projekt kopiert. Kein Paket, keine Abhängigkeit, einfach Ihr Code.

0:27 Das klingt nach einem Rückschritt und ist eine bewusste, gut begründete Entscheidung. Warum, schauen wir uns heute an.

UI mit shadcn/ui

0:35 Der Weg führt von der ersten Einrichtung bis zu einer eigenen Verteilstelle für Firmenkomponenten — und am Ende sogar zu Arbeitsabläufen, bei denen ein KI-Assistent die Installation übernimmt. Dazwischen liegen die Themen, die den Alltag bestimmen: wie man Komponenten zusammensetzt statt sie mit Einstellungen zu überladen, und wie man ein durchgängiges Erscheinungsbild hinbekommt, ohne in jeder Datei Farben zu setzen.

0:57 Die erste Frage ist heute besonders aufschlussreich, weil der Umstieg für jede Ausgangslage anders aussieht. Wer aus einer klassischen Bibliothek kommt, muss sich vor allem an den Gedanken gewöhnen, dass es keine Aktualisierung per Befehl mehr gibt. Wer schon mit Tailwind arbeitet, wird sich sofort zu Hause fühlen — ohne das ist der erste Tag eine doppelte Umstellung.

1:18 Sagen Sie mir das ruhig vorab, dann gewichte ich die Erklärungen entsprechend.

Grundlagen & Philosophie

1:23 Beginnen wir mit der Denkweise, denn sie erklärt alles Weitere. Der Unterschied zu allem, was Sie kennen, ist keine technische Feinheit, sondern eine andere Antwort auf die Frage, wem der Code gehört. Und mit dieser Antwort handelt man sich Vorteile und Pflichten gleichzeitig ein. Wer diesen Handel verstanden hat, kann für jedes Projekt selbst entscheiden, ob er sich lohnt.

1:44 Stellen Sie sich den Unterschied zwischen einer Mietwohnung und einem Eigenheim vor. In der Mietwohnung ist alles gepflegt, die Heizung wird gewartet, aber Sie dürfen keine Wand versetzen. Im Eigenheim können Sie alles umbauen — müssen sich aber auch selbst um das Dach kümmern. Genau das ist der Handel hier. Die Komponenten liegen als ganz normale Dateien in Ihrem Projekt. Sie können jede Zeile ändern, und niemand hindert Sie daran.

2:10 Dafür gibt es keinen Befehl mehr, der Ihnen die Aktualisierung abnimmt. Beides gehört zusammen. Der erste Punkt ist das Versprechen, der zweite die praktische Konsequenz — und die ist bemerkenswert. Weil die Komponenten nur eine dünne Schicht über den zugrundeliegenden Bausteinen sind, kann darunter die Grundlage gewechselt werden, ohne dass sich Ihr Aufrufcode ändert.

2:31 Genau das ist gerade passiert: Base UI ist neuer Standard, Radix funktioniert weiter. Diese Beweglichkeit hat eine klassische Bibliothek nicht — dort wäre so etwas eine Hauptversion mit Umstellungsaufwand für alle. Der fünfte Punkt ist der ehrliche, und ich möchte ihn nicht schönreden. Der Besitz am Code kostet etwas: Wenn oben eine Verbesserung oder ein Fehlerfix entsteht, kommt der nicht von selbst zu Ihnen.

2:55 Es gibt Werkzeuge dafür, die wir uns ansehen — aber es bleibt eine bewusste Handlung. Für ein Projekt, dessen Oberfläche stark eigen ist, lohnt sich das um ein Vielfaches. Für ein internes Verwaltungswerkzeug, das einfach nur ordentlich aussehen soll, ist eine klassische Bibliothek womöglich die ruhigere Wahl. Hier sehen Sie, wie eine solche Komponente von innen aussieht — und das ist bewusst unspektakulär.

3:20 Eine Funktion, die aus einer Variante und einer Größe eine Liste von Klassen zusammenbaut. Keine Magie, keine versteckte Ebene. Der entscheidende Punkt: Wenn Sie eine weitere Variante brauchen, fügen Sie eine Zeile hinzu. Sie müssen keine Erweiterungsschnittstelle suchen und keine Anfrage stellen. Diese Datei gehört Ihnen. Das ist der ganze Trick, und er ist gerade deshalb wirkungsvoll, weil er so wenig Neues erfindet.

3:46 Die erste Aufgabe ist wieder eine Entscheidungsaufgabe. Benennen Sie beide Seiten des Handels — was Sie gewinnen und was Sie sich einhandeln. Und entscheiden Sie sich begründet für eine der beiden Grundlagen. Für neue Projekte ist die Antwort in der Regel die neue Standardwahl; für bestehende Projekte mit vorhandenen Komponenten spricht viel für Kontinuität.

4:06 Wer schnell fertig ist, nimmt sich eine kopierte Schaltfläche vor und erweitert sie um eine eigene Variante. Das ist der Moment, in dem der Besitz am Code konkret wird. Der erste Punkt ist die häufigste Fehlerwartung, und sie kommt oft erst nach Monaten zum Vorschein: Jemand sucht nach dem Aktualisierungsbefehl und findet keinen.

4:25 Der zweite verdient eine Warnung. Beide Grundlagen im selben Projekt zu verwenden bedeutet doppelte Datenmengen und, schlimmer, zwei verschiedene Vorstellungen davon, wie Overlays sich verhalten. Der dritte ist die ironischste Falle: Wer nie etwas anpasst, hat den ganzen Nachteil des Modells gewählt und keinen einzigen Vorteil genutzt.

Projekt-Setup & CLI v4

4:44 Jetzt richten wir das Ganze ein. Die Kommandozeile ist hier mehr als ein Installationshelfer — sie ist der Weg, auf dem Code in Ihr Projekt kommt und auf dem Sie später Änderungen von oben abgleichen. Ein paar Befehle lohnt es sich zu kennen. Vor allem einer davon beantwortet die Frage, die im ersten Kapitel offengeblieben ist: Wie kommt man an Verbesserungen, wenn der Code einem selbst gehört?

5:06 Die Konfigurationsdatei ist die Schaltzentrale, und sie beantwortet vor allem eine Frage: Wohin gehören die Dateien? Denn anders als bei einem Paket, das an einer festgelegten Stelle im Abhängigkeitsordner landet, wandern diese Komponenten mitten in Ihre Ordnerstruktur. Die Werkzeuge müssen also wissen, wie diese Struktur aussieht.

5:24 Bemerkenswert sind außerdem die beiden Befehle zum Abgleich — sie sind die Antwort auf die Frage, die im ersten Kapitel offen blieb: Wie komme ich an Verbesserungen, wenn ich den Code besitze? Der letzte Punkt löst das Aktualisierungsproblem auf eine Art, die ich für angemessen halte. Der eine Befehl zeigt Ihnen, was sich oben geändert hat, im Vergleich zu Ihrem Stand.

5:46 Sie sehen also die Verbesserung und Ihre eigene Anpassung nebeneinander und entscheiden. Das ist mehr Arbeit als eine automatische Aktualisierung — aber es ist auch ehrlicher. Bei einer klassischen Bibliothek passiert dieselbe Änderung, nur unsichtbar, und Sie merken es erst, wenn etwas anders aussieht. Der dritte Schritt lohnt tatsächlich einen Moment Aufmerksamkeit.

6:08 Die konfigurierten Pfad-Kürzel müssen zu Ihrer Projektstruktur passen — und wenn Ihr Projekt nicht der Standardvorlage folgt, tun sie das nicht automatisch. Der Fehler zeigt sich dann als Importe, die ins Leere zeigen, direkt nach dem ersten Hinzufügen. Fünf Minuten Kontrolle jetzt sparen die Suche danach. Der letzte Punkt ist ein netter Komfort: Sie können die Dokumentation im Terminal nachschlagen, ohne den Browser zu wechseln.

6:33 Vier Befehle, die den gesamten Lebenszyklus abdecken. Beachten Sie beim Hinzufügen etwas Praktisches: Abhängigkeiten werden mitgenommen. Wer einen Dialog holt, bekommt auch, was der Dialog braucht — Sie müssen die Kette nicht selbst verfolgen. Die beiden unteren Befehle sind die für später: der eine zeigt Unterschiede zum aktuellen Stand oben, der andere hilft bei größeren Umstellungen.

6:57 Gewöhnen Sie sich an, den Vergleich gelegentlich laufen zu lassen — etwa quartalsweise. Sonst wächst der Abstand still. Setzen Sie jetzt Ihr Projekt auf. Nehmen Sie sich danach unbedingt einen Moment für etwas, das die Aufgabe nicht ausdrücklich verlangt: Öffnen Sie die Datei der installierten Schaltfläche und lesen Sie sie durch.

7:16 Es sind vierzig Zeilen, und Sie werden feststellen, dass Sie jede davon verstehen. Genau dieser Moment ist das eigentliche Verkaufsargument dieses Ansatzes — bei einer klassischen Bibliothek würden Sie an dieser Stelle in einer übersetzten Datei landen und wieder herausklicken. Der zweite Punkt ist der häufigste Fehlstart, und er hat ein verwirrendes Symptom: Die Komponenten sind da, sie funktionieren, aber sie sehen aus wie roher Text.

7:40 Ursache ist fast immer eine unvollständige Tailwind-Einrichtung — die Gestaltungsvariablen sind schlicht nicht definiert. Der letzte Punkt ist eine Warnung vor einer Einbahnstraße: Es gibt einen Befehl, der die Verbindung zur Kommandozeile kappt und alles vollständig herauslöst. Das kann richtig sein, ist aber schwer rückgängig zu machen. Nicht aus Neugier ausprobieren.

Kernkomponenten & Komposition

8:02 Jetzt zum Bauen. Das Leitprinzip dieses Kapitels steht in der Notiz und lohnt sich zu merken: zusammensetzen statt einstellen. Es ist der Unterschied zwischen einer Komponente mit vierzig Einstellungen und einer, die man wie Bausteine kombiniert. Das klingt nach einer Geschmacksfrage und hat handfeste Folgen dafür, wie gut eine Komponentensammlung altert.

8:23 Das Steckplatz-Muster löst ein Problem, das jeder kennt, der schon einmal einen Link haben wollte, der aussieht wie eine Schaltfläche. Der übliche Weg wäre eine Einstellung — soll ich eine Schaltfläche oder ein Link sein? Und dann kommt die nächste Anforderung, und die Liste wächst. Hier stülpen Sie die Gestaltung stattdessen einfach über das, was drin steht. Die Schaltfläche bleibt eine Schaltfläche, sie leiht ihr Aussehen nur an das Kind aus.

8:48 Ein Muster, unendlich viele Fälle — statt für jeden Fall eine Einstellung. Der dritte Punkt verdient Hervorhebung, weil er stillschweigend viel Qualität mitbringt. Die Formularkomponenten verdrahten Beschriftung, Eingabefeld, Hilfetext und Fehlermeldung so, dass eine Vorlesesoftware sie korrekt zusammen vorträgt. Das ist die Sorte Arbeit, die im Projektplan nie auftaucht und die deshalb regelmäßig unterbleibt.

9:12 Hier bekommen Sie sie geschenkt — vorausgesetzt, Sie nutzen die vorgesehenen Bausteine, statt sich Ihr Formular aus rohen Eingabefeldern selbst zu bauen. Beim dritten Schritt eine praktische Empfehlung. Wenn Sie eine Abwandlung brauchen — sagen wir eine Warnvariante in Rot — dann tragen Sie die in der Variantendefinition ein, statt an der Aufrufstelle Klassen dranzuhängen.

9:33 Der Unterschied zeigt sich beim zehnten Mal: Im ersten Fall steht die Warnvariante einmal definiert und wird überall gleich verwendet. Im zweiten Fall haben Sie zehn leicht unterschiedliche Rottöne im Projekt und niemand weiß, welcher der richtige ist. Vier Zeilen, die das Prinzip auf den Punkt bringen. Was am Ende im Dokument steht, ist ein echter Link — mit allem, was dazugehört: Er lässt sich in einem neuen Tab öffnen, das Kontextmenü funktioniert, Suchmaschinen erkennen ihn.

10:00 Optisch ist er eine Schaltfläche. Der übliche Gegenentwurf, eine Schaltfläche mit einem Klickhandler, der zur Adresse springt, sieht identisch aus und ist in all diesen Punkten schlechter. Eine kleine Sache, an der man gute von schneller Arbeit unterscheiden kann. Zwei Übungen, die zusammen den typischen Anwendungsalltag abdecken.

10:19 Beim Formular achten Sie bitte auf die Fehlermeldungen — prüfen Sie mit der Tastatur, ob Sie beim Absenden im ersten fehlerhaften Feld landen und ob die Meldung dort vorgelesen wird. Bei der Tabelle werden Sie merken, dass die Sortier- und Filterlogik gar nicht aus den Komponenten kommt, sondern aus einer eigenen Bibliothek darunter.

10:38 Die Komponenten liefern nur das Aussehen. Diese Arbeitsteilung ist wichtig zu verstehen. Der zweite Punkt ist ein Fehler, der einen beim ersten Mal ratlos macht. Das Übertragen der Gestaltung funktioniert nur mit genau einem Kind — bei zweien weiß niemand, wohin damit, und es gibt einen Laufzeitfehler. Die Lösung ist ein umschließendes Element, aber am besten merkt man sich einfach die Regel.

11:00 Der erste Punkt ist der grundsätzliche: Sobald Sie anfangen, Einstellungen hinzuzufügen, um Sonderfälle abzudecken, sind Sie wieder in der Welt, aus der dieser Ansatz herausführen wollte.

Theming & Design-System

11:12 Kommen wir zur Gestaltung. Die zentrale Frage lautet: Wie erreicht man, dass eine Farbänderung an einer Stelle in der ganzen Anwendung ankommt — und dass die dunkle Darstellung keine zweite Baustelle wird? Die Antwort ist eine Ebene dazwischen. Sie werden sehen, dass die Antwort erstaunlich wenig mit Komponenten zu tun hat und fast alles mit Benennung.

11:32 Der entscheidende Gedanke sind die bedeutungstragenden Namen. Eine Komponente sagt nicht "dieses Blau", sondern "die Hauptfarbe". Was die Hauptfarbe ist, steht an einer einzigen Stelle. Der Gewinn zeigt sich bei der dunklen Darstellung: Sie schreiben keine einzige Komponente um, Sie definieren nur die Variablen neu. Zur Farbdarstellung noch eine Anmerkung — das hier verwendete Farbmodell ist wahrnehmungsbasiert.

11:56 Zwei Farben mit gleicher Helligkeitsangabe wirken auch tatsächlich gleich hell, was beim klassischen Modell nicht der Fall ist. Für konsistente Paletten ist das ein echter Vorteil. Der dritte Punkt ist neu und praktisch: Eine Zusammenstellung aus Farben, Schriften, Symbolen und Eckenrundung lässt sich als Einheit sichern und auf ein anderes Projekt übertragen.

12:17 Für Firmen mit mehreren Anwendungen ist das die schnellste Antwort auf die Frage, wie das nächste Projekt gleich aussieht wie das letzte. Und der letzte Punkt ist der, den man beherzigen sollte, wenn eigene Komponenten dazukommen: Halten Sie sich an dieselben Konventionen, sonst zerfällt das System an den Rändern. Der zweite Schritt ist der wichtigste, und ich formuliere ihn als Regel: Die dunkle Darstellung ist eine Frage der Variablen, nie eine Frage der Komponente.

12:43 Wenn Sie in einer Komponente eine Bedingung für den dunklen Modus finden, ist das ein Zeichen, dass eine Variable fehlt. Der Grund ist Arithmetik — bei fünfzig Komponenten mit je einem Sonderfall haben Sie fünfzig Stellen, an denen die dunkle Darstellung kaputtgehen kann. Mit der Variablenebene haben Sie eine. Hier sieht man die ganze Mechanik auf acht Zeilen.

13:04 Oben die Grundwerte, unten die Abweichungen für die dunkle Darstellung — und beachten Sie, dass unten nur steht, was sich unterscheidet. Alles andere wird geerbt. Die Komponenten selbst kommen in diesem Beispiel gar nicht vor, und das ist der Punkt: Sie fragen nach der Hintergrundfarbe und bekommen, was gerade gilt. Wenn Sie irgendwann eine dritte Darstellung brauchen, etwa mit erhöhtem Kontrast, ist das ein weiterer Block hier und keine Zeile in einer Komponente.

13:31 Bauen Sie jetzt Ihr eigenes Erscheinungsbild. Der Prüfstein ist scharf formuliert und lohnt die Ernstnahme: Der Wechsel zur dunklen Darstellung darf keine Komponentenänderung erfordern. Testen Sie das, indem Sie umschalten und gezielt nach Stellen suchen, die nicht mitgehen — meist sind es Schatten, Trennlinien und Zustände beim Überfahren mit der Maus, die jemand direkt hingeschrieben hat.

13:52 Die Zusatzaufgabe, das Ganze auf ein zweites Projekt zu übertragen, zeigt dann den eigentlichen Wert. Die ersten beiden Punkte sind zwei Seiten derselben Sache und die verbreitetsten Fehler überhaupt. Der dritte ist die Verbindung zum Thema Mehrsprachigkeit: Wer in seiner Gestaltung mit "links" und "rechts" arbeitet statt mit "Anfang" und "Ende", bekommt bei einer Sprache mit umgekehrter Schriftrichtung eine Oberfläche, die halb gespiegelt ist.

14:17 Das kostet nichts, wenn man es von Beginn an berücksichtigt, und wird zum Umbau, wenn nicht.

Blocks, Registries & Skalierung im Team

14:23 Bis hierhin ging es um einzelne Komponenten. Jetzt wird es größer: fertige Abschnitte statt einzelner Bausteine — und die Frage, wie eine Firma ihre eigenen Komponenten so verteilt, dass jedes Projekt sie mit einem Befehl bekommt. Für Firmen mit mehreren Anwendungen ist das der Punkt, an dem aus einer Bibliothek ein Design-System wird.

14:42 Der zweite Teil ist der interessantere, und er ist verblüffend schlicht gelöst. Eine Verteilstelle für Komponenten ist nichts weiter als ein Repository mit einer Beschreibungsdatei. Kein Server, keine Registrierung, keine Veröffentlichung in einem Paketverzeichnis. Für Firmen bedeutet das: Ihr internes Design-System kann morgen installierbar sein, ohne dass jemand eine Infrastruktur aufbauen muss.

15:05 Das ist die Art von niedriger Einstiegshürde, die darüber entscheidet, ob so etwas tatsächlich gemacht wird oder auf der Wunschliste bleibt. Der erste Punkt hat einen praktischen Nutzen, den man erlebt haben muss. Ein fertiger Abschnitt — sagen wir eine Anmeldeseite oder ein Übersichtsbereich mit Seitenleiste — ist eben nicht nur eine Ansammlung von Einzelteilen.

15:26 Es sind die richtigen Abstände, das durchdachte Verhalten auf kleinen Bildschirmen, die sinnvollen Zustände. Das kostet Sie sonst einen Tag und sieht danach schlechter aus. Zum Anpassen ist es trotzdem Ihr Code — genau darin liegt der Unterschied zu einer fertigen Vorlage. Der letzte Schritt ist der, an dem Teams langfristig scheitern oder nicht.

15:45 Wenn Ihre Firmenkomponenten verteilt sind und jemand sie in einem Projekt anpasst, haben Sie eine Abweichung. Das ist erlaubt und oft richtig — aber jemand muss den Überblick behalten. Der Vergleichsbefehl ist dafür das Werkzeug, und die Verabredung im Team ist der wichtigere Teil: Wer entscheidet, ob eine lokale Anpassung zurück in die gemeinsame Fassung wandert?

16:06 Zwei Wege, die dasselbe tun. Oben aus dem öffentlichen Verzeichnis, unten aus einer beliebigen Adresse. Der untere ist der für Firmen interessante — Ihre Komponente liegt auf Ihrem Server oder in Ihrem Repository, und die Installation läuft trotzdem mit demselben Befehl wie alles andere. Ein Hinweis dazu, der auf der nächsten Folie noch als Stolperstein wiederkommt: Öffentlich erreichbar heißt öffentlich erreichbar.

16:30 Wenn Ihre Komponenten Interna enthalten, gehört ein Zugriffsschutz davor. In dieser Übung stellen Sie eine eigene Komponente bereit. Sie werden überrascht sein, wie wenig dazugehört — eine Beschreibungsdatei an der richtigen Stelle, mehr nicht. Nutzen Sie den Moment für ein Gedankenexperiment: Welche drei Komponenten aus Ihrem aktuellen Projekt würden andere Teams sofort brauchen können?

16:53 Das sind die Kandidaten für Ihr erstes internes Angebot. Und wer Zeit hat, bindet einen fertigen Anmeldebereich ein und passt ihn ins eigene Erscheinungsbild ein. Der erste Punkt ist die logische Folge aus dem Besitz am Code: Wer angepasste Komponenten ungeprüft überschreibt, verliert seine Anpassung — und meist merkt es niemand sofort.

17:13 Immer erst vergleichen. Der dritte Punkt ist eine Kompatibilitätsfalle: Fertige Abschnitte gibt es für beide Grundlagen, und wer den falschen zieht, holt sich die zweite Bibliothek ins Projekt, die er eigentlich vermeiden wollte. Und der letzte ist die Sicherheitsanmerkung von eben.

AI-gestützte Workflows & Ausblick

17:29 Zum Abschluss ein Blick nach vorn. Coding-Assistenten sind im Alltag angekommen, und dieses Ökosystem hat darauf früh reagiert — mit einer Schnittstelle, über die ein Assistent die Kommandozeile bedienen kann. Schauen wir uns an, was das praktisch bedeutet und wo Vorsicht angebracht ist. Und wir ziehen dabei eine Grenze, die im Umgang mit Assistenten generell hilft: Was ist verlässlich, und was ist eine Vermutung?

17:53 Der wesentliche Unterschied zu dem, was Sie vielleicht erwarten: Der Assistent erfindet die Komponente nicht, er installiert sie. Er ruft dieselben Befehle auf, die Sie auch aufrufen würden — nur ausgelöst durch einen Satz statt durch Tippen. Das ist der entscheidende Punkt für die Qualität. Generierter Code bringt geraten aussehende Ergebnisse; eine ausgelöste Installation bringt exakt die geprüfte Komponente aus der Verteilstelle.

18:18 Der Assistent übernimmt die Fleißarbeit, nicht die Substanz. Der zweite Punkt ist der wichtigere und wird oft übersehen. Ein Assistent ohne Kontext rät — er kennt Ihre Verteilstelle nicht, weiß nicht, wie Ihre Komponenten heißen, und schreibt im Zweifel etwas Ähnliches selbst. Mit dem passenden Kontextpaket weiß er, was verfügbar ist, und greift darauf zu.

18:39 Der Unterschied im Ergebnis ist erheblich: einmal eine Komponente, die zufällig ähnlich aussieht, einmal genau Ihre. Diese Vorbereitung ist der ganze Aufwand, und er ist einmalig. Der vierte Punkt betrifft alle mit bestehenden Projekten. Der Wechsel der Grundlage muss nicht an einem Tag passieren — beide können nebeneinander laufen, solange Sie es planvoll tun.

19:01 Die pragmatische Empfehlung: Bei Änderungen an einer Komponente stellen Sie sie gleich mit um, statt ein Umstellungsprojekt aufzusetzen. Nach einem halben Jahr ist der Großteil erledigt, ohne dass jemand einen Termin dafür verteidigen musste. Wichtig ist nur, dass es ein Ziel gibt und nicht ein Dauerzustand wird. Das ist kein Code, sondern ein Satz — und genau das ist die Botschaft. Was hier passiert, ist eine Übersetzung von Absicht in Befehle.

19:27 Bemerkenswert daran ist die zweite Hälfte des Satzes: Der Assistent installiert nicht nur, er setzt die Teile auch zusammen. An dieser Stelle beginnt allerdings der Bereich, in dem Sie hinschauen müssen — die Installation ist verlässlich, das Zusammensetzen ist eine Vermutung darüber, was Sie wollten. Beides zu unterscheiden, ist der Kern eines vernünftigen Umgangs damit.

19:49 Richten Sie die Anbindung ein und lassen Sie eine Komponente per Satz installieren. Und tun Sie danach das, was auf der nächsten Folie als Stolperstein steht: Schauen Sie sich an, was tatsächlich in Ihrem Projekt gelandet ist. Nicht aus Misstrauen, sondern weil es Ihr Code ist — und das war ja der ganze Punkt dieses Ansatzes.

20:07 Wer die Zusatzaufgabe angeht, lässt eine Komponente auf die neue Grundlage umstellen und prüft das Ergebnis besonders sorgfältig. Der erste Punkt ist die wichtigste Regel für diesen ganzen Bereich. Ein Assistent, der Dateien in Ihr Projekt schreibt, ist ein sehr schneller Kollege — und wie bei jedem Kollegen schauen Sie sich die Änderung an, bevor sie eingecheckt wird.

20:28 Der letzte Punkt ist der subtilere: Generierter Code funktioniert oft, passt aber stilistisch nicht — andere Klassennamen, andere Struktur, feste Farben statt Variablen. Das fällt einzeln kaum auf und lässt ein Design-System über Monate ausfransen. Fassen wir zusammen. Der Kern ist der Besitz am Code — die Komponenten liegen bei Ihnen, mit allen Freiheiten und der Pflicht, gelegentlich abzugleichen.

20:51 Die Kommandozeile ist dabei mehr als ein Installationshelfer: Sie ist auch der Weg zu Verbesserungen von oben. Beim Bauen setzen Sie zusammen, statt einzustellen. Die Gestaltung läuft über eine Variablenebene, damit die dunkle Darstellung keine zweite Baustelle wird. Und mit einer eigenen Verteilstelle wird aus all dem ein Design-System, das andere Teams mit einem Befehl bekommen.

Fragen & Weiterarbeiten

21:14 Alle Komponenten und Übungslösungen liegen in der Freigabe. Nehmen Sie sich vor allem Ihr Erscheinungsbild und Ihre erste eigene Verteilstelle mit — das sind die beiden Dinge, die im eigenen Haus am schnellsten Wirkung zeigen. Die offizielle Seite ist gleichzeitig Dokumentation, Verzeichnis und Sammlung fertiger Abschnitte; ein Blick dorthin lohnt sich immer wieder, weil laufend Neues dazukommt.

21:36 Bei Fragen aus dem eigenen Projekt melden Sie sich gern. Vielen Dank für Ihre Aufmerksamkeit.