Eine UI-Komponentenbibliothek nach den Gestaltungsregeln aufbauen und pflegen

## Für jede Aufgabe die maßgebliche Vorgabe lesen und bei Abweichungen dem Code folgen Ordne die Aufgabe vor der Bearbeitung ein und lies die Quelle, die sie regelt. - Lies für Komponentenverhalten oder APIs den Leitfaden zur öffentlichen API, die Implementierung und eine benachbarte freigegebene Komponente. - Lies für die Gestaltung die ausführliche Gestaltungsvorgabe, die Token-Datei für die Kompilierzeit, die Themendatei für die Laufzeit und die angrenzenden bereichsgebundenen Stile. - Lies bei Änderungen am Erstellungsvorgang die Erstellungskonfiguration und jeden Vertrag eines angepassten Plugins, bevor du die Verarbeitungskette änderst. - Lies für Tests die eigene Testkonfiguration und benachbarte Tests; lies für die Dokumentation die Abgleichsmatrix. - Löse Widersprüche in dieser Reihenfolge: Quellcode und aktive Konfiguration, Repository-Regeln, Fachdokumentation, dann allgemeine Erfahrung. - Wenn Quellcode und Dokumentation voneinander abweichen, folge dem Quellcode und berichtige die veraltete Dokumentation innerhalb desselben freigegebenen Umfangs. - Behandle Kurzübersichten als Verweise auf maßgebliche Abschnitte, nicht als eigenständige Kopien der Regeln. - Erfinde niemals eine API und verlasse dich bei versionsabhängigem Verhalten nicht auf dein Gedächtnis; prüfe die installierte Version und die mitgelieferte Dokumentation. Führe vor der Implementierung die betroffenen Exporte, Stile, Tests, Register der Beispielansichten, Dokumente und unveränderlichen Erstellungsbedingungen auf. ## Jeder Komponente einen eigenen Ordner mit Code, Stilen und Tests geben Gib jeder Komponente einen eigenen Ordner mit ihrer Implementierung, ihrer bereichsgebundenen Stildatei, ihrem Export-Einstieg und ihrem dort abgelegten Komponententest. Füge öffentliche Wert- und Typ-Exporte getrennt hinzu und registriere jede erforderliche Beispielansicht. - Verwende typisierte Funktionskomponenten, lege Standardwerte in der Parameterdestrukturierung fest und setze einen stabilen Anzeigenamen. - Erweitere die Attribute des passenden nativen Elements und lasse nur kollidierende Felder aus. - Schreibe Komponenten- und Typnamen mit der im Repository vorgeschriebenen Groß- und Kleinschreibung, Stildateien im konfigurierten Dateinamensformat und bereichsgebundene Klassennamen nach der festgelegten Klassenkonvention. - Bewahre die strenge null-Prüfung und die Regeln für isolierte Module; vermeide untypisierte Auswege und verwende ausdrückliche reine Typ-Exporte. - Halte import-Anweisungen am Anfang, verwende die konfigurierten Projektaliasnamen und setze keine globalen Selektoren in bereichsgebundene Komponentenstile. - Setze Klassen über die bereichsgebundene Stilzuordnung oder die freigegebene Klassenhilfsfunktion zusammen, statt erzeugte Klassennamen fest einzutragen. - Beschränke wiederverwendbare Hilfsfunktionen auf eine klare Aufgabe und lege sie dort ab, wo die Repository-Konvention es vorsieht. Ändere die öffentliche Schnittstelle einer Komponente nicht, ohne zugleich ihre Exporte, Tests, Beispiele und API-Dokumentation zu aktualisieren. ## Farben und Rundungen über gemeinsame Gestaltungswerte statt fester Rohwerte festlegen Halte für unterschiedliche Aufgaben getrennte Token-Ebenen vor: Variablen zur Kompilierzeit unterstützen Berechnungen und Mixins, während benutzerdefinierte CSS-Eigenschaften zur Laufzeit den Nutzenden das Überschreiben von Themen ermöglichen. Behandle die beiden Ebenen nicht als austauschbar. - Halte die Benennung von CSS Modules und die Token-Einspeisung zwischen Erstellungs- und Testkonfiguration konsistent. - Bevorzuge semantische Laufzeit-Tokens in Komponentenstilen; verwende Variablen zur Kompilierzeit nur, wenn eine Vorverarbeitung nötig ist. - Drücke Farbe, Fokus, Radius, Höhenwirkung, Typografie, Schriftstärke und Bewegung über die semantischen Rollen des Systems statt über vereinzelte Rohwerte aus. - Vermeide reine Extremwerte und allgemeine kühle Standardwerte, wenn die Gestaltungssprache getönte Flächen, warme Textfarben oder markentypische Fokuszustände festlegt. - Bewahre bewusst gestaltete Komponentenumrisse, Zustandsdarstellungen und Schattenregeln, statt sie zu einem einzigen allgemeinen Muster einzuebnen. - Führe globale Schriftarten, Themenvariablen und Rücksetzungen hinter einem einzigen globalen Stileinstieg zusammen. - Beachte die Einstellung für verringerte Bewegung und erhalte einen sichtbaren Fokus, die Tastaturbedienung, lesbaren Kontrast und dokumentierte Barrierefreiheitsrollen. Entnimm genaue Werte und komponentenspezifische Ausnahmen der maßgeblichen Gestaltungsvorgabe und dem aktuellen Quellcode, niemals dem Gedächtnis. ## Tastaturbedienung und Barrierefreiheit jeder Komponente testen Verwende die eigene Testkonfiguration des Repositorys mit der dort festgelegten DOM-Umgebung, den Einrichtungsdateien, Vergleichsregeln, Aliasnamen und der Verarbeitung von CSS Modules. Verschiebe Testeinstellungen nicht in eine Erstellungskonfiguration, die das aktive Testprogramm ignoriert. - Lege Komponententests bei den Komponenten ab und verwende die freigegebenen Hilfswerkzeuge zum Darstellen, Abfragen und Nachbilden von Nutzerinteraktionen. - Decke Darstellung, durch props gesteuerte Klassen, Rückruffunktionen, Verhalten im deaktivierten Zustand, Zustandsänderungen und einschlägige Barrierefreiheitsrollen ab. - Prüfe die Tastaturbedienung mit den vom Komponentenmuster verlangten Tasten, einschließlich Fokusverschiebung, Aktivierung, Schließen und Richtungssteuerung. - Prüfe bereichsgebundene Klassen über die importierte Stilzuordnung statt über erzeugte Zeichenkettenliterale. - Prüfe imperative APIs, indem du sie innerhalb der Zustandsgrenze des Testrahmens aufrufst und ihr eingebundenes Ergebnis abwartest; stelle eine API, die keine Komponente ist, nicht als JSX dar. - Verwalte gemeinsame Testhilfen zentral und verwende realistische Nutzerinteraktionen statt Ereignisabkürzungen niedriger Ebene. - Erreiche die konfigurierten Abdeckungsgrenzen und dokumentiere jede beabsichtigte Ausnahme, statt die Abdeckung mit wenig aussagekräftigen Fällen aufzublähen. Führe bei einem Fehler zuerst einen gezielten fehlschlagenden Test aus, danach den betroffenen Testsatz und schließlich vor Abschluss den gesamten vorgeschriebenen Testsatz. ## Den Build modular halten, damit nur genutzte Komponenten geladen werden Behandle angepasste Erstellungsplugins, Paketexporte und Ressourcenregeln als Verträge mit den Nutzenden der Bibliothek. - Bewahre getrennte ES-module- und CommonJS-Ausgaben mit intakten Modulgrenzen, damit ungenutzte Komponenten weiterhin durch Tree Shaking entfernt werden können. - Behandle das Framework und freigegebene Hilfspakete als extern, wenn sie Peer-Abhängigkeiten sind; füge ohne ausdrückliche Anforderung keine Laufzeitabhängigkeiten hinzu. - Bewahre die CSS-Codeaufteilung und den Mechanismus, der die Stile jeder Komponente ihrem JavaScript-Einstieg zuordnet. - Halte den Einstieg der globalen Stilvorlage vollständig und verhindere zugleich, dass Ressourcen ungenutzter Komponenten in die Bundles der Nutzenden gelangen. - Befolge die Repository-Richtlinie zum Kopieren und Einbetten von Ressourcen, einschließlich der Anforderungen an Schriftformat und öffentlichen Pfad. - Stimme Paketexporttabellen, veröffentlichte Dateien und Deklarationen von Seiteneffekten auf die erzeugte Struktur ab. - Ändere die Erstellungslogik erst nach dem Lesen der Verträge der angepassten Plugins und prüfe anschließend sowohl import-Anweisungen auf Komponentenebene als auch den globalen Stileinstieg. Erzeugte Verzeichnisse für Verteilung, Beispielerstellung und Abdeckung sind Ergebnisse und keine Bearbeitungsbereiche; sie dürfen nur eingereicht werden, wenn die Repository-Richtlinie dies ausdrücklich verlangt. ## Bei jeder Komponentenänderung Doku und Beispielansichten mitziehen Aktualisiere jede maßgebliche Stelle, die von einer Komponentenänderung betroffen ist. - Änderungen an API oder props aktualisieren das API-Handbuch anhand des Quellcodes; Stiländerungen aktualisieren die ausführliche Gestaltungsvorgabe. - Änderungen an der visuellen Sprache aktualisieren das Gestaltungskonzept, und neue Komponenten aktualisieren die nutzergerichtete Eingabeaufforderung oder die Katalogvorgabe. - Änderungen an Komponentenanzahl oder Abdeckung aktualisieren über das freigegebene Erzeugungswerkzeug jedes gespiegelte readme. - Die Registrierung von Beispielansichten kann auf Routenmetadaten, eine Renderer-Zuordnung und einen Startseitenkatalog verteilt sein; aktualisiere jedes unabhängige Register. - Leite maschinenlesbare Anzahlen aus maßgeblichen Metadaten ab, statt sie von Hand mehrfach zu führen. - Führe die Dokumentationsabgleichsprüfung aus und kläre, welche Beispiel- oder erzeugten Ansichten sie nicht untersucht. - Erzeuge versionsverwaltete Artefakte mit dem freigegebenen Befehl neu, statt erzeugte Ergebnisse direkt zu bearbeiten. Prüfe nach Registrierungsänderungen, ob die Auswahl der Beispielroute die vorgesehene Seite darstellt; ein hervorgehobenes Menü bei leerem Hauptbereich weist meist auf einen fehlenden Registereintrag hin. ## Bekannte Fehler wie Massenersetzungen und leere Beispielseiten vermeiden Verwende eng begrenzte, überprüfbare Vorgänge für Änderungen, die unbemerkt viele Dateien beschädigen können. - Prüfe bei skriptgesteuerten Ersetzungen jedes Ziel sofort, berücksichtige unveränderliche Zeichenkettenoperationen und vermeide Muster, die über Markup in Anführungszeichen hinweg fehlschlagen. - Gib den vorgeschriebenen Ausgabepfad an, wenn ein Testwerkzeug strukturierte Ergebnisse schreibt, statt eine Standarddatei vorauszusetzen. - Bette bei der Umwandlung von DOM in ein Bild die erforderlichen Schriftdeklarationen in das Aufnahme-Wurzelelement ein, wenn das Darstellungsprogramm das Schriftregister des Dokuments nicht lesen kann. - Gestalte beabsichtigte interne Komponentenabhängigkeiten nicht allein deshalb um, um eine oberflächliche Tree-Shaking-Kennzahl zu verbessern. - Optimiere die Paketgröße, indem du bedarfsgesteuerte import-Anweisungen erhältst und verhinderst, dass ungenutzte große Ressourcen, Schriftarten und Komponenten in die Bundles der Nutzenden gelangen. - Untersuche leere Beispielseiten, indem du jedes unabhängige Seitenregister prüfst, bevor du die Komponentenimplementierung änderst. Überführe jeden bestätigten wiederkehrenden Fehler in eine gezielte automatische Prüfung, wenn das Repository einen stabilen Ort dafür vorsieht. ## Vor der Übergabe alle CI-Prüfungen bestehen Führe die dokumentierte Formatierungsprüfung, lint, Komponententests und die Bibliothekserstellung in der vom Repository geforderten Reihenfolge aus. Führe vor dem Vorschlagen eines Beitrags den vollständigen CI-Befehl aus. Bestätige Folgendes: - Alle geänderten Komponenten, Exporte, Tests, Dokumentationen und Register der Beispielansichten sind abgeglichen. - Abdeckungs- oder Komponentenanzahlabzeichen wurden neu erzeugt, wenn sich ihre Eingaben geändert haben. - Keine nicht freigegebene Laufzeitabhängigkeit und kein erzeugtes Ergebnis ist in die Änderung gelangt. - Die Verträge für modulare Ausgabe, CSS-Aufteilung und Ressourcenladung gelten weiterhin. - Die visuelle Änderung entspricht den aktuellen Token- und Komponentenvorgaben. - Der abschließende Unterschied enthält nur die beabsichtigten Änderungen an Quellcode und Dokumentation. Wenn eine vorgeschriebene Prüfung fehlschlägt, behebe den Fehler und führe die betreffende Prüfung erneut aus, bevor du den Unterschied vorlegst. Verwende das Beitragsformat des Repositorys und führe Freigabe- oder Veröffentlichungsabläufe nur aus, wenn die Aufgabe sie ausdrücklich umfasst. Berichte genau, welche Prüfungen ausgeführt und welche weitergehenden Prüfungen bewusst aus dem Umfang ausgeschlossen wurden.