Die Vorteile der Verwendung benutzerdefinierter Eigenschaften in Designsystemen und Komponentenbibliotheken.
Ich bin Dave und Senior-Frontend-Entwickler bei Nordhealth. Ich bin am Design und der Entwicklung unseres Designsystems Nord beteiligt. Dazu gehört auch die Entwicklung von Webkomponenten für unsere Komponentenbibliothek. Ich möchte Ihnen gern erläutern, wie wir die Probleme beim Gestalten von Webkomponenten mithilfe von benutzerdefinierten CSS-Eigenschaften gelöst haben und wie Sie benutzerdefinierte Eigenschaften in Designsystemen und Komponentenbibliotheken nutzen konnten.
So entwickeln wir Webkomponenten
Zur Erstellung unserer Webkomponenten verwenden wir Lit. Diese Bibliothek enthält umfangreiches Codebausteine wie Status, Bereichsstile, Vorlagen und mehr. Er ist nicht nur schlank, sondern baut auch auf nativen JavaScript-APIs auf. So können wir ein schlankes Codepaket bereitstellen, das die bereits vorhandenen Browserfunktionen nutzt.
Das Beste an Web-Komponenten ist jedoch, dass sie mit fast jedem vorhandenen JavaScript-Framework oder sogar ohne Framework funktionieren. Sobald auf das Haupt-JavaScript-Paket auf der Seite verwiesen wird, ähnelt die Verwendung einer Webkomponente der Verwendung eines nativen HTML-Elements. Das einzige wirkliche Zeichen dafür, dass es sich nicht um ein natives HTML-Element handelt, ist der einheitliche Bindestrich innerhalb der Tags, der dem Browser anzeigt, dass es sich um eine Webkomponente handelt.
Shadow-DOM-Stil-Kapselung
Ähnlich wie native HTML-Elemente ein Shadow DOM haben, tun es auch Webkomponenten. Shadow DOM ist eine verborgene Baumstruktur von Knoten innerhalb eines Elements. Am besten lässt sich dies visualisieren, indem Sie den Web Inspector öffnen und die Option „Shadow DOM-Baum anzeigen“ aktivieren. Sehen Sie sich dann ein natives Eingabeelement im Inspector an. Sie können es jetzt öffnen und alle darin enthaltenen Elemente sehen. Sie können dies sogar mit einer unserer Webkomponenten ausprobieren. Sehen Sie sich unsere benutzerdefinierte Eingabekomponente an, um ihr Shadow DOM zu sehen.
Einer der Vorteile (oder Nachteile, je nach Sichtweise) von Shadow DOM ist die Stilkapselung. Wenn Sie CSS in Ihrer Webanwendung schreiben, können diese Stile nicht austreten und sich auf die Hauptseite oder andere Elemente auswirken. Sie sind vollständig in der Komponente enthalten. Außerdem kann CSS, das für die Hauptseite oder eine übergeordnete Webkomponente geschrieben wurde, nicht in Ihre Webkomponente eindringen.
Diese Kapselung der Stile ist ein Vorteil in unserer Komponentenbibliothek. Es gibt uns eher die Garantie, dass eine unserer Komponenten, wenn jemand verwendet wird, wie beabsichtigt aussieht, unabhängig von den Stilen, die auf der übergeordneten Seite angewendet wurden. Zur Sicherheit fügen wir all: unset;
auch der Wurzel oder dem „Host“ aller Webkomponenten hinzu.
Was ist jedoch, wenn jemand, der Ihre Webkomponente verwendet, einen berechtigten Grund hat, bestimmte Stile zu ändern? Vielleicht gibt es eine Textzeile, die aufgrund des Kontexts mehr Kontrast benötigt, oder ein Rahmen muss dicker sein? Wenn keine Stile in Ihre Komponente gelangen können, wie können Sie diese Stiloptionen freischalten?
Hier kommen benutzerdefinierte CSS-Properties ins Spiel.
Benutzerdefinierte CSS-Properties
Benutzerdefinierte Eigenschaften sind sehr gut benannt. Dabei handelt es sich um CSS-Eigenschaften, die Sie selbst benennen und alle erforderlichen Werte anwenden können. Die einzige Voraussetzung ist, dass Sie ihnen zwei Bindestriche voranstellen. Nachdem Sie die benutzerdefinierte Property deklariert haben, kann der Wert in Ihrem CSS mithilfe der Funktion var()
verwendet werden.
Bei der Übernahme werden alle benutzerdefinierten Properties übernommen. Das entspricht dem üblichen Verhalten regulärer CSS-Properties und -Werte. Jede benutzerdefinierte Property, die auf ein übergeordnetes Element oder das Element selbst angewendet wird, kann als Wert für andere Properties verwendet werden. Wir nutzen benutzerdefinierte Eigenschaften in großem Umfang für unsere Designtokens, indem wir sie über unser CSS-Framework auf das Stammelement anwenden. Das bedeutet, dass alle Elemente auf der Seite diese Tokenwerte verwenden können, sei es eine Webkomponente, eine CSS-Hilfsklasse oder ein Entwickler, der einen Wert aus unserer Liste von Tokens übernehmen möchte.
Mithilfe der Funktion var()
können benutzerdefinierte Eigenschaften übernommen werden, um das Shadow-DOM unserer Webkomponenten zu durchdringen und Entwicklern eine detailliertere Kontrolle beim Stylen unserer Komponenten zu ermöglichen.
Benutzerdefinierte Eigenschaften in einer Nord-Webkomponente
Immer, wenn wir eine Komponente für unser Designsystem entwickeln, gehen wir beim CSS durchdacht vor. Unser Ziel ist es, schlanker, aber gut verwaltbarer Code zu verwenden. Die Designtokens, die wir haben, sind in unserem Haupt-CSS-Framework für das Stammelement als benutzerdefinierte Eigenschaften definiert.
Auf diese Tokenwerte wird dann in unseren Komponenten verwiesen. In einigen Fällen wird der Wert direkt auf die CSS-Eigenschaft angewendet. In anderen Fällen wird eine neue kontextbezogene benutzerdefinierte Property definiert und der Wert darauf angewendet.
Außerdem abstrahieren wir einige Werte, die für die Komponente spezifisch sind, aber nicht in unseren Tokens enthalten sind, und wandeln sie in eine benutzerdefinierte Kontexteigenschaft um. Benutzerdefinierte Eigenschaften, die für die Komponente kontextabhängig sind, bieten uns zwei wesentliche Vorteile. Erstens: Wir können unser CSS schlanker gestalten, da dieser Wert auf mehrere Properties innerhalb der Komponente angewendet werden kann.
Und zweitens lassen sich Änderungen am Komponentenstatus und an Variationen sehr klar erkennen. Nur die benutzerdefinierte Eigenschaft muss geändert werden, um all diese Eigenschaften zu aktualisieren, z. B. wenn Sie einen Hover- oder aktiven Status oder in diesem Fall eine Variation gestalten.
Der größte Vorteil besteht jedoch darin, dass wir durch die Definition dieser benutzerdefinierten Kontexteigenschaften für eine Komponente eine Art benutzerdefinierte CSS-API für jede unserer Komponenten erstellen, die vom Nutzer dieser Komponente genutzt werden kann.
Das obige Beispiel zeigt eine unserer Webkomponenten mit einer kontextbezogenen benutzerdefinierten Property, die über einen Selektor geändert wurde. Das Ergebnis dieses gesamten Ansatzes ist eine Komponente, die dem Nutzer ausreichend Flexibilität beim Styling bietet und gleichzeitig die meisten der tatsächlichen Stile im Auge behält. Außerdem haben wir als Komponentenentwickler die Möglichkeit, die vom Nutzer angewendeten Stile abzufangen. Wenn wir eine dieser Eigenschaften anpassen oder erweitern möchten, ist das möglich, ohne dass der Nutzer seinen Code ändern muss.
Wir finden diesen Ansatz sehr wirkungsvoll – nicht nur für uns als Entwickler unserer Designsystemkomponenten, sondern auch für unser Entwicklungsteam, wenn diese Komponenten in unseren Produkten verwenden.
Benutzerdefinierte Eigenschaften weiter optimieren
Zum Zeitpunkt der Erstellung dieses Dokuments werden diese kontextbezogenen benutzerdefinierten Properties nicht in unserer Dokumentation offengelegt. Wir möchten jedoch dafür sorgen, dass unser Entwicklungsteam diese Properties verstehen und nutzen kann. Unsere Komponenten sind in npm mit einer Manifestdatei gepackt, die alle notwendigen Informationen über die Komponenten enthält. Die Manifestdatei wird dann als Daten verarbeitet, wenn unsere Dokumentationswebsite bereitgestellt wird. Dies geschieht mit Eleventy und der zugehörigen Funktion Global Data. Wir planen, diese kontextbezogenen benutzerdefinierten Eigenschaften in diese Manifest-Datendatei aufzunehmen.
Ein weiterer Bereich, den wir verbessern möchten, ist die Art und Weise, wie diese kontextbezogenen benutzerdefinierten Eigenschaften Werte erben. Wenn Sie derzeit beispielsweise die Farbe von zwei Trennlinien anpassen möchten, müssen Sie die Ausrichtung auf beide Komponenten speziell mit Selektoren vornehmen oder die benutzerdefinierte Eigenschaft direkt auf das Element mit dem Stilattribut anwenden. Das mag in Ordnung erscheinen, aber es wäre hilfreicher, wenn der Entwickler diese Stile für ein enthaltenes Element oder sogar auf Stammebene definieren könnte.
Der Wert für die benutzerdefinierte Property muss direkt auf der Komponente festgelegt werden, da wir sie über die Auswahl für den Komponentenhost auf demselben Element definieren. Die globalen Designtokens, die wir direkt in der Komponente verwenden, werden direkt weitergeleitet, sind von diesem Problem nicht betroffen und können sogar von übergeordneten Elementen abgefangen werden. Wie können wir das Beste aus beiden Welten bekommen?
Private und öffentliche benutzerdefinierte Eigenschaften
Private benutzerdefinierte Eigenschaften wurden von Lea Verou zusammengestellt. Dabei handelt es sich um eine kontextbezogene "private" benutzerdefinierte Eigenschaft auf der Komponente selbst, die jedoch auf eine "öffentliche" benutzerdefinierte Eigenschaft mit einem Fallback festgelegt wurde.
Wenn wir unsere kontextbezogenen benutzerdefinierten Eigenschaften auf diese Weise definieren, können wir immer noch alle Dinge tun, die wir zuvor getan haben, z. B. globale Tokenwerte übernehmen und Werte im gesamten Komponentencode wiederverwenden. Die Komponente übernimmt jedoch auch neue Definitionen dieser Eigenschaft für sich selbst oder für ein übergeordnetes Element.
Auch wenn es möglicherweise argumentiert, dass diese Methode nicht wirklich „privat“ ist, denken wir, dass dies eine ziemlich elegante Lösung für ein Problem ist, über das wir uns Sorgen machen. Bei Gelegenheit werden wir dies in unseren Komponenten angehen, damit unser Entwicklungsteam mehr Kontrolle über die Komponentennutzung hat und gleichzeitig von unseren Sicherheitsvorkehrungen profitiert.
Wir hoffen, diese Informationen zur Verwendung von Webkomponenten mit benutzerdefinierten CSS-Eigenschaften waren für Sie hilfreich. Lasst uns wissen, was ihr davon haltet. Wenn ihr eine dieser Methoden in eurer eigenen Arbeit verwenden möchtet, könnt ihr mich auf Twitter unter @DavidDarnes finden. Sie finden Nordhealth auch auf Twitter unter @NordhealthHQ sowie den Rest meines Teams, das hart daran gearbeitet hat, dieses Designsystem zusammenzustellen und die in diesem Artikel erwähnten Funktionen umzusetzen: @Viljamis, @WickyNilliams und @eric_habich.
Hero-Image von Dan Cristian Pădureț