CSS-Teile bewahren Sie vor einem Albtraum

Notwendiger Kontext

Kürzlich habe ich mir einen bekannten Podcast angehört, und die großartigen Moderatoren haben über Webkomponenten gesprochen und alle guten, schlechten und hässlichen Aspekte der verschiedenen Spezifikationen und Funktionen der Webkomponenten aufgelistet.

Danke an Chris Coyier und Dave Rupert für die absolut faire Folge und das tolle Gespräch. Hören Sie sich die Folge hier an:

Shop-Talkshow

Wie auch immer, tief in dieser Episode war ich überrascht, dass CSS Parts es auf die Liste der Bösewichte geschafft haben, obwohl ich einige der Gründe erkennen kann, warum die Leute vielleicht denken, sie seien nicht die Besten. Ich bin der Meinung, dass CSS-Teile nicht nur ziemlich gut sind, sie ersparen uns allen, die sie verwenden, auch ein Szenario, das VIEL ärgerlicher und frustrierender ist, als wenn wir nicht jedes einzelne Element innerhalb des Schattenstamms einer Webkomponente genau so formatieren können du willst.

Lassen Sie es mich erklären, aber zuerst MEHR Kontext!

Webkomponenten wurden hauptsächlich für die Nutzung durch Dritte entwickelt

Ich kann nicht explizit bestätigen, dass alle folgenden Aussagen wahr sind, aber meine persönliche Meinung – die ich in den letzten Jahren während meiner täglichen Arbeit beim Schreiben, Verwenden und Spezifizieren von Webkomponentenfunktionen entwickelt habe – ist, dass die vorhandenen Webkomponentenspezifikationen und -funktionen wurden alle entwickelt, um den Anwendungsfall „Drittanbieterkomponente“ zu lösen. Das heißt, Webkomponenten wurden entwickelt, um eine ganz bestimmte Situation zu unterstützen: ein Komponentenautor, der ein Tool erstellt, das andere Verbraucher aus dem Internet herunterladen und in ihren Apps verwenden.

Ich bin der Meinung, dass viele der von Spezifikationsschreibern und Browser-Implementierern gewählten Ansätze sehr sinnvoll sind, wenn man die Funktionen von Webkomponenten durch die Linse des Anwendungsfalls „Drittanbieterkomponente“ betrachtet. Nehmen wir zum Beispiel die Schwere der Kapselung im Shadow-Dom-Stil. Wenn Sie eine Komponente aus dem Internet in Ihre App ziehen, ist es dann nicht wunderbar, sich keine Sorgen machen zu müssen, dass das CSS dieser Komponente eine Ihrer Seiten irgendwie beschädigen könnte? Ist es nicht wunderbar, sich nicht um die interne Struktur einer Komponente kümmern zu müssen, die Sie nicht geschrieben haben, sondern diese Komponente wie eine Blackbox behandeln und über eine wohldefinierte API-Oberfläche mit ihr interagieren zu können?

Das größte Problem beim Verständnis der Funktionsweise von Webkomponenten besteht darin, dass sich die Branche seit der Erstellung der Webkomponentenspezifikationen weiterentwickelt hat und heutzutage 99 % der Komponenten, die wir in unseren Apps verwenden, nicht aus externen Quellen stammen . Wenn wir heutzutage an Komponenten denken, denken wir meistens an eine „Erstanbieterkomponente“, die wir oder unser Team geschrieben haben, und nicht an eine Person im Internet. Wir verwenden nicht so viele externe Komponenten in unseren Anwendungen, daher erscheinen uns Webkomponenten-APIs, die hauptsächlich für diesen Anwendungsfall entwickelt wurden, seltsam, insbesondere wenn wir versuchen, Webkomponenten auch zu verwenden, um Erstanbieterkomponenten für uns selbst zu erstellen.

Bei allem anderen, was ich in diesem Artikel sagen werde, gehe ich davon aus, dass ich mich auf die Situation der „Drittanbieterkomponente“ beziehe. Stellen Sie sich vor, dass es sich bei der Komponente, von der ich spreche, um ein npm-Paket handelt, das Sie heruntergeladen haben, und dass es eine GitHub-Readme-Datei und Patchnotizen usw. gibt, Sie (oder Ihr Team) sie aber nicht selbst für Ihre eigene App geschrieben haben.

CSS-Teile sind keine großartige Schnittstelle für die Gestaltung von Komponenten, die Sie für sich selbst oder Ihr Team schreiben und über die Sie die volle Kontrolle haben.

CSS-Teile sind Teil der öffentlichen API einer Webkomponente

Gut gestaltete Komponenten bieten verschiedene Möglichkeiten, mit ihnen zu interagieren. Hervorragende Webkomponenten verfügen über Slots für benutzerdefiniertes HTML, benutzerdefinierte CSS-Eigenschaften für benutzerdefinierte Designs und CSS-Teile für benutzerdefinierte Stile. Die Leute von der Shop Talk Show diskutierten über CSS-Parts mit dem Hintergrund, dass sie für die Freiformgestaltung umständlich seien, aber ich würde CSS-Parts nicht so sehen. Ich würde sie als eine weitere öffentliche API-Oberfläche für die Komponente betrachten, ähnlich wie Attribute oder Eigenschaften. Die Leute machen sich normalerweise keine allzu großen Sorgen darüber, dass sie keine benutzerdefinierten Eigenschaften oder Attribute für Komponenten erstellen können, die sie aus dem Internet beziehen. Ich denke, CSS-Teile sind die gleiche Idee. Der Komponentenautor bestimmt die Teile der internen Vorlage, deren Stil „ok to style“ ist, wie Sie es wünschen. Daher sollte es nicht unbedingt eine Erwartung sein, jedes einzelne interne Element in dieser Shadow-Dom-Webkomponente formatieren zu können.

Und wer könnte besser wissen, auf welche Teile einer komplexen Vorlage ein Stil angewendet werden kann, als der Autor der Komponente? Wenn Sie eine Komponente aus dem Internet herunterladen, nur um alle Stile neu zu schreiben, und dabei möglicherweise die Barrierefreiheit usw. zerstören, warum haben Sie die Komponente dann überhaupt installiert? Ich verstehe die Attraktivität des „Ich weiß, was ich tue“-Selektors für Schattenwurzeln, den viele Leute befürwortet haben, aber im nächsten Abschnitt werde ich beleuchten, warum ich denke, dass es so ist, eine definierte Styling-API-Oberfläche zu haben Die Trennung von der internen DOM-Struktur ist wirklich erstaunlich und sollte dafür gefeiert werden, dass sie uns allen Entwicklern hilft, nicht verrückt zu werden.

Stichwort altmodische Filmtrailer-Stimme

In einer Welt, in der es den Selektor „Ich weiß, was ich tue“ gibt, CSS-Teile jedoch nicht

Lassen Sie uns in eine imaginäre Welt springen, in der es keine CSS-Teile gibt und ein „Ich weiß, was ich tue“-Selektor (nennen wir ihn aus Nostalgiegründen /deep/) existiert und „so“ ist Sie sollen die interne DOM-Vorlage einer Shadow-Root-Webkomponente formatieren.

Und Sie benötigen eine solche Komponente für Ihre App, also laden Sie ein npm-Paket herunter

npm i some-awesome-package@1.2.3

und haben Sie den folgenden HTML-Code in Ihrer Bewerbung:

<some-awesome-component></some-awesome-component>

Die Komponente „Some Awesome Component“ enthält ein Div, das standardmäßig rot ist und keine benutzerdefinierten CSS-Eigenschaften verwendet. Und zunächst einmal ist das rote Div vollkommen ok!

Aber dann entscheiden Sie, dass Sie die Farbe des roten Divs in „rebeccapurple“ ändern müssen. Also schreiben Sie dieses CSS:

@layer my-overides {
  some-awesome-component /deep/ div.the-red-div {
    background: rebeccapurple;
  }
}

the-red-div ist ein schrecklicher Name für eine Klasse, aber hey, die interne Struktur einer Shadow-Dom-Webkomponente interessiert niemanden, oder? Sie können nicht mit der Außenwelt in Konflikt geraten, daher können Komponentenautoren schreckliche Klassennamen schreiben, wenn sie möchten.

Und weil wir uns in unserer imaginären Welt befinden, in der /deep/ existiert, funktioniert alles! Das rote Div ist jetzt lila und alles ist Coolio.

Sie ignorieren die winzige kognitive Dissonanz in unserem Gehirn, dass .the-red-div eine Farbe hat, die nicht rot ist. Das ist ein Problem von morgen.

Süß!

Dann fügt der Komponentenautor eine Funktion hinzu und veröffentlicht einen Patch-Bump.

Sie sind mit dem Versand beschäftigt und haben nebenbei ein nicht verwandtes Paket neu installiert und den neuesten Patch von Some Awesome Component heruntergeladen, und das rote Div ist wieder da!

Was gibt es? Sie durchsuchen die Patchnotizen und finden:

## 1.2.4
- [a987s83] Added cool button, fixed a11y issues

Scheint gut, warum ist das CSS kaputt gegangen? Changelog-Notizen enthalten keine Hinweise. Sie überfliegen also die neuesten PRs und sehen nichts, was Ihnen ins Auge springt.

Also starten Sie Ihre Anwendung und prüfen den Schattenstamm und das rote Div ist ein Jetzt! Und der Autor der Komponente hat erkannt, dass der Klassenname „the-red-div“ allgemeiner hätte sein sollen, und hat ihn in „colorful“ geändert.

Okay, gut, also bearbeiten Sie Ihr CSS wie folgt:

@layer my-overides {
  some-awesome-component /deep/ .colorful {
    background: rebeccapurple;
  }
}

Und es funktioniert wieder einwandfrei!

Dann veröffentlicht der Autor nächste Woche einen weiteren Patch-Bump.

Spring zurück in die reale Welt

Der direkte CSS-Selektorzugriff auf DOM, den Sie nicht kontrollieren, ist ein gewaltiges Unterfangen

Sehen Sie das Muster und das damit verbundene Problem beim direkten Auswahlzugriff auf interne Vorlagen, die Sie nicht besitzen oder kontrollieren?

Änderungen an der internen Vorlage werden zwangsläufig außerhalb der Kontrolle von Ihnen, dem Komponentenkonsumenten, vorgenommen. Und unweigerlich werden diese Änderungen auf eine Weise erfolgen, die für Sie fast unsichtbar ist, ohne JEDES EINZELNE TEIL Ihrer laufenden App visuell zu überprüfen, entweder manuell oder mit unzuverlässigen visuellen Regressionstest-Tools. Wenn Sie eine Komponente aus dem Internet nutzen, kommt eine Art Vertrag zustande. Der Komponentenautor ist Eigentümer des Shadow-Dom, und Sie als Verbraucher besitzen das :host-Element (das HTML-Tag selbst in Ihrem Code, den Sie schreiben). Das Überschreiten dieser Grenze ohne einen bestehenden Vertrag ist eine Garantie für brüchigen Code.

Lustige Tatsache, diese Sprödigkeit tritt auch auf, wenn in JS direkte Shadow-Dom-QuerySelectors für DOM-Elemente ausgeführt werden. Wenn Ihre App darauf angewiesen ist, dass ein Element immer existiert, ist dies nicht der Fall. Wenn Sie eine Abfrage in ein DOM durchführen, das Sie nicht kontrollieren können, wird eines Tages ein Element nicht mehr vorhanden sein. Entweder ist es ein anderes Element oder es hat eine andere Klasse/ein anderes Attribut/eine andere ID.

Aber CSS Parts stehen Ihnen zur Seite

Da es sich bei CSS-Teilen um einfache Zeichenfolgen handelt, die selbst keine DOM-Elemente sind, schützt ihre Verwendung Ihre Anwendung vor brüchigem Code. Autoren von Drittanbietern werden niemals testen, ob ein Div IMMER für immer ein Div ist. Wenn sie jedoch einen CSS-Teil erstellen, wissen sie, dass sie eine öffentliche API für die Komponente erstellen, die nicht ohne eine grundlegende Änderung entfernt oder geändert werden kann. Und wenn Sie CSS-Teile verwenden, anstatt das Schatten-DOM direkt abzufragen, kann der Komponentenautor diesen CSS-Teil im Schatten-DOM verschieben und Ihr Anwendungscode wird nicht beschädigt.

Da außerdem CSS-Teilnamen Beziehungen, Konzepte und Funktionen implizieren, wäre es für einen Komponentenautor schwierig, eine Komponente so umzugestalten, dass der CSS-Teil seine Bedeutung wesentlich ändert. Sie wissen also nicht nur, dass Ihr CSS-Teil, der Code verwendet, nicht kaputt geht, wenn der Autor der Komponente Änderungen vornimmt, ohne es Ihnen mitzuteilen, sondern Sie können auch einigermaßen sicher sein, dass der CSS-Teil im Verhältnis zum Gesamtbild immer dasselbe ist Komponente. Daher ist es ziemlich sicher, dass die Stile, die Sie auf dieses Teil anwenden, für dieses Teil immer „Sinn ergeben“, auch wenn sich die Komponente im Laufe der Zeit weiterentwickelt.

Einen Schritt weiter

Ich habe ein paar Kommentare von sehr klugen und wertvollen Branchenleuten über den Aufwand von CSS-Teilen gesehen und darüber, dass das Hinzufügen eines direkten Shadow-Dom-Zugriffs über Selektoren viel bequemer wäre. Wenn sich im Laufe der Zeit nichts ändern würde, würde ich voll und ganz zustimmen. Da sich Komponenten jedoch im Laufe der Zeit ändern, wage ich anzunehmen, dass der direkte Shadow-DOM-Zugriff schmerzhafter sein wird, als sich merken zu müssen, welche CSS-Teile zur Verwendung verfügbar sind.

Wenn es Diskussionen darüber gibt, wie die Grenze zwischen „der App“ und dem Schattendom innerhalb einer Komponente überschritten werden kann, würde ich mich immer für einen benannten strukturellen Vertragsansatz wie CSS-Teile gegenüber dem direkten Selektorzugriff einsetzen. Meiner Ansicht nach musste jeder, der CSS-Teile für klobig und schrecklich hält, einfach nicht seine gesamte App durchforsten und nach allen Stellen suchen, an denen eine Shadow-Root-Vorlage ohne sein Wissen geändert wurde :)

Abschluss

CSS-Teile sind großartig und wenn Sie sie verwenden, möchten Sie, auch wenn Sie zu 100 % ein großartiger Entwickler sind und wissen, was Sie tun, zu 100 % nicht den Schmerz haben, möglicherweise all dieses benutzerdefinierte CSS optimieren zu müssen Sie haben jedes Mal geschrieben, wenn es einen Patch-Bump für die von Ihnen verwendeten Komponenten gibt. Sie wissen definitiv, was Sie tun, aber wir alle möchten verhindern, dass unsere Apps zufällig kaputt gehen, und das ist es, was das direkte Shadow-DOM-Styling bewirken wird. Ein „Ich weiß, was ich tue“-Selektor wird Ihr Styling auf jeden Fall zum Funktionieren bringen, aber es wird nur garantiert funktionieren, wenn Sie die Paketversion, die Sie gestaltet haben, buchstäblich nie aktualisieren. Wenn Sie die Version aktualisieren, müssen Sie jedes Mal ein Auge auf all diese „Ich weiß, was ich tue“-Stile haben.

Meiner Meinung nach ist das eine Verschwendung unserer kostbaren Zeit. Verwenden Sie einfach CSS-Teile und ermutigen Sie Komponentenentwickler, sie zu den von ihnen geschriebenen Komponenten hinzuzufügen.

Das obige ist der detaillierte Inhalt vonCSS-Teile bewahren Sie vor einem Albtraum. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!