Ein bisschen über Web Component Bibliotheken

Kürzlich ist eine Flut von Web Components-Nachrichten auf meinen Schreibtisch gekommen, also dachte ich, ich fasse sie hier zusammen.

Meiner Meinung nach ist einer der besten Anwendungsfälle für Web Components Pattern Libraries. Anstatt zum Beispiel <ul class="nav nav-tabs"> zu verwenden, wie man es in Bootstrap tun würde, oder <div class="tabs">, wie man es in Bulma tun würde, würde man ein benutzerdefiniertes Element wie <designsystem-tabs> verwenden.

Die neue Shoelace-Bibliothek verwendet den sl-Namensraum für ihre Komponenten. Es ist eine komplette Pattern Library, die vollständig in Web Components implementiert ist. Die Tabs dort sind also <sl-tab-group>-Elemente.

Warum ist das gut? Nun, zum einen bringt es ein Komponentenmodell mit sich. Das bedeutet, wenn Sie an einer Komponente arbeiten, hat diese eine Vorlage und ein Stylesheet, die zusammen liegen. Wenn man unter die Haube von Shoelace schaut, kann man sehen, dass alles auf Stencil basiert.

Ein weiterer Vorteil ist, dass Komponenten den Shadow DOM verwenden können (und auch tun). Dies bietet eine Form der Isolation, die direkt von der Web-Plattform stammt. Für CSS-Leute wie uns bedeutet dies, dass das Styling für einen Tab in der Tab-Komponente mit einer .tab-Klasse (hey, wow, cool) erfolgt, aber in dieser Komponente isoliert ist. Selbst mit einem so generischen Namen kann ich nicht versehentlich eine andere Komponente auf der Seite beeinflussen, die diese generische Klasse verwendet, noch kann externes CSS in die Innereien hier eingreifen. Der Shadow DOM ist eine Art Sicherheitsmauer, die verhindert, dass Stile nach außen lecken oder nach innen sickern.

Ich habe auch das FAST-Framework¹ gesehen, das ebenfalls ein Satz von Komponenten ist. Es hat Tabs, die als <fast-tabs> definiert sind. Das erinnert mich an eine weitere Sache, die ich am Ansatz von Web Components als Pattern Library mag: Es fühlt sich API-gesteuert an, beginnend schon mit dem Namen der Komponente selbst, was buchstäblich das ist, was man im HTML verwendet. Die Attribute dieses Elements können völlig frei erfunden sein. Es scheint der aufkommende Standard zu sein, dass man die Attribute, die man ebenfalls erfindet, um die Komponente zu steuern, nicht einmal mit einem data-*-Präfix versehen muss. Wenn ich also eine Tabs-Komponente erstellen würde, könnte sie so aussehen: <chris-tabs active-tab="lunch" variation="rounded">.

Der vielleicht größte Akteur, der Web Components für eine Pattern Library verwendet, ist Ionic. Ihre Tabs sind <ion-tabs>, und man kann sie verwenden, ohne ein anderes Framework einzubinden (obwohl sie neben ihrem eigenen Stencil auch Angular, React und Vue unterstützen). Ionic hat viele Fortschritte bei dieser Web Components-Sache gemacht, zuletzt mit der Unterstützung von Shadow Parts. Hier erklärt Brandy Carney noch einmal die Kapselung:

Der Shadow DOM ist nützlich, um zu verhindern, dass Stile aus Komponenten herauslecken und unbeabsichtigt auf andere Elemente angewendet werden. Zum Beispiel weisen wir unserer ion-button-Komponente die Klasse .button zu. Wenn ein Ionic Framework-Benutzer die Klasse .button für eines seiner eigenen Elemente festlegen würde, würde es in früheren Versionen des Frameworks die Ionic-Button-Stile erben. Da ion-button jetzt eine Shadow Web Component ist, ist dies kein Problem mehr.

Aufgrund dieser Kapselung können Stile jedoch auch nicht in innere Elemente einer Shadow-Komponente eindringen. Das bedeutet, dass ein Benutzer, wenn eine Shadow-Komponente Elemente innerhalb ihres Shadow-Trees rendert, diese inneren Elemente nicht mit seinem CSS ansprechen kann.

Die Kapselung ist eine gute Sache, aber sie macht das Styling tatsächlich "schwieriger" (bewusst). Es gibt ein wichtiges CSS-Konzept zu wissen: CSS Custom Properties durchdringen den Shadow DOM. Es wurde jedoch entschieden – und ich denke zu Recht –, dass die "Variabilisierung" jedes einzelnen Elements in einem Designsystem kein kluger Weg ist. Stattdessen geben sie jedem Teil des HTML im Shadow DOM einen Part, wie <div part="icon">, was uns dann die Möglichkeit gibt, mit CSS von außen "hineinzureichen", wie custom-component::part(icon) { }.

Ich denke, part-basierte Styling-Hooks sind größtenteils in Ordnung und ein guter Weg für Pattern Libraries wie diese, aber ich gebe zu, dass mich ein Teil davon stört. Die Selektoren funktionieren nicht so, wie man es erwarten würde. Man kann zum Beispiel keine Dinge bedingt auswählen. Man kann auch keine Kinder auswählen oder die Kaskade verwenden. Mit anderen Worten, es ist nur ein Einzelfall, oder als würde man mit der Hand direkt durch eine Membran greifen. Man kann nach vorne greifen und entweder das Ding schnappen oder nicht, aber man kann nichts anderes tun.

Apropos Dinge, die Leute stören: Andrea Giammarchi hat einen guten Punkt über den aktuellen Zustand von Web Components gemacht

Jede einzelne Bibliothek, die neu startet, einschließlich meiner, schlägt vor, dass wir die Bibliothek importieren müssen, um ein "portables Custom Element" zu definieren.

Google empfiehlt immer LitElement. Microsoft möchte, dass Sie FASTElement verwenden. Stencil hat sein eigenes Component. hyperHTML hat sein eigenes Component. Niemand verwendet "rohe" Web Components. Das ist seltsam! Was mich am schlimmsten daran stört, ist, dass Web Components eigentlich dieses "native Plattform"-Ding sein sollen, was bedeutet, dass wir uns nicht auf eine bestimmte Technologie einlassen müssen, um sie zu nutzen. Wenn wir das tun, sind wir genauso davon abhängig, als würden wir einfach React oder etwas anderes verwenden.

Andrea hat einige Ideen in diesem Artikel, einschließlich der Verwendung von einer neuen und kleineren Bibliothek. Ich denke, ich würde gerne eine Pattern Library sehen, die überhaupt keine Bibliothek verwendet.