Teamkonventionen und Styleguide

Ohne gemeinsame Konventionen werden Tailwind-Projekte uneinheitlich. Ein Entwickler schreibt überall p-4, ein anderer verwendet px-4 py-4. Einer nutzt @apply großzügig, ein anderer vermeidet es vollständig. Ein Team-Styleguide dokumentiert die Entscheidungen Ihres Teams, damit alle Tailwind auf dieselbe Weise schreiben. Dadurch werden Code-Reviews schneller und die Codebasis leichter wartbar.

Auch wenn das Prettier-Plugin die Reihenfolge automatisch erzwingt, sollte Ihr Styleguide dokumentieren, warum die kanonische Reihenfolge verwendet wird und wie sie aussieht. So verstehen Entwickler sie, statt sie blind zu befolgen. Nehmen Sie die Reihenfolge der Gruppen auf – Layout, Größen, Abstände, Typografie, Darstellung und Interaktion –, damit Teammitglieder vorhersehen können, wohin eine Klasse gehört.

Eine häufige Ursache für Uneinigkeit ist die Frage, wann Utilities mit @apply extrahiert werden sollen. Legen Sie eine klare Regel fest: Verwenden Sie @apply beispielsweise nur, wenn sich ein Muster mehr als dreimal in verschiedenen Komponenten wiederholt UND nicht mit einer gemeinsamen JSX- oder Template-Komponente gelöst werden kann. So verhindern Sie eine voreilige Abstraktion und erkennen gleichzeitig echte Duplikate.

Tailwinds Klammersyntax wie w-[347px] ist leistungsfähig, kann aber zu einer Vielzahl schwer wartbarer magischer Zahlen führen. Ihr Styleguide sollte verlangen, dass beliebige Werte in einem Kommentar begründet werden und Werte, die mehr als einmal vorkommen, stattdessen als benanntes Token im extend-Block des Themes hinzugefügt werden.

Jeder Eintrag in der safelist erhöht die Kosten jedes Builds. Ihr Styleguide sollte verlangen, dass Safelist-Klassen einen Kommentar enthalten, der erklärt, warum sie nicht statisch erkannt werden können. Erstellen Sie einen Prüfplan für die Safelist – beispielsweise vierteljährlich –, um Einträge für entfernte oder umgebauten Funktionen zu löschen.

Wenn Ihr Projekt @apply verwendet, um Komponentenklassen zu erstellen, legen Sie eine Benennungskonvention fest. Von BEM inspirierte Namen wie .btn-primary und .card-body sind eine verbreitete Wahl. Dokumentieren Sie, welches Benennungsmuster Ihr Team verwendet, und stellen Sie sicher, dass benutzerdefinierte Komponentenklassen niemals mit den eigenen Utility-Namen von Tailwind kollidieren.

Dokumentieren Sie, wie Ihr Team mit responsivem Design umgeht. Verbreitete Konventionen sind immer Mobile-First (Basisstile gelten für Mobilgeräte, Präfixe fügen Verhalten für größere Bildschirme hinzu), die Verwendung nur einer Teilmenge der Breakpoints (z. B. ausschließlich md und lg) sowie der Verzicht darauf, ein Präfix ohne den zugehörigen Basisfall anzuwenden, damit die Stile korrekt kaskadieren.

Wählen und dokumentieren Sie für das gesamte Projekt eine Strategie für den Dark Mode – entweder die class-Strategie oder die media-Strategie – und mischen Sie diese niemals. Legen Sie fest, welche Elemente immer eine Dark-Variante benötigen (Hintergründe, Text, Rahmen) und welche ihre Darstellung übernehmen können. Fügen Sie eine Checkliste hinzu, mit der neue Komponenten vor dem Mergen auf vollständige Dark-Mode-Unterstützung geprüft werden.

Integrieren Sie Tailwind-Konventionen in Ihren PR-Review-Prozess. Eine kurze Checkliste in der PR-Vorlage erinnert sowohl den Autor als auch den Reviewer daran, wichtige Konventionen zu prüfen. Dazu gehören beispielsweise: Klassen sind sortiert, es gibt keine ungesicherte dynamische Klassenerzeugung, beliebige Werte sind kommentiert, Dark-Mode-Varianten sind vollständig und es sind keine widersprüchlichen Utilities vorhanden.

Schreiben Sie den Styleguide in eine STYLE_GUIDE.md-Datei, die in das Repository eingecheckt wird. Halten Sie ihn in der Nähe des Codes und nicht in einem separaten Wiki, das veralten kann. Jede Konvention sollte eine kurze Begründung enthalten, damit neue Teammitglieder das Warum verstehen und sie leichter akzeptieren und befolgen können. Prüfen Sie den Guide vierteljährlich und aktualisieren Sie ihn, wenn sich das Projekt weiterentwickelt.

Ein Styleguide ist nur dann wirksam, wenn neue Entwickler ihn lesen. Fügen Sie in der README Ihres Projekts und in der Onboarding-Checkliste für neue Teammitglieder einen Link zum Tailwind-Styleguide ein. Erwägen Sie ein kurzes Quiz oder eine Übung, in der neue Entwickler die Konventionen an einer Übungskomponente anwenden, bevor sie produktiven Code bearbeiten.

In dieser Lektion haben Sie Folgendes gelernt: Konventionen für @apply und beliebige Werte definieren, um Fehlverwendung zu verhindern, Konventionen in PR-Checklisten verankern, um eine konsistente Prüfung zu ermöglichen, und den Styleguide im Repository dokumentieren, damit er aktuell bleibt. Als Nächstes erstellen wir den vollständigen Hero- und Navigationsbereich einer Landingpage.