Jedes Mal, wenn eine Gruppe von Webkomponenten-Standards in einem Artikel oder in Kommentaren erwähnt wird, passiert fast dasselbe: Menschen, die oft nur eine sehr geringe Vorstellung davon haben, worum es geht, beginnen, Expertenmeinungen auszutauschen. Jedes Mal werden Diskussionen in ein und dasselbe Szenario verschoben, dessen Name sich mit dem Wort "Turm" reimt. Und ich hätte sehr gerne einen positiven, konstruktiven und Übergang zu Fragen der praktischen Anwendung. In diesem Artikel werde ich versuchen, die überwiegende Mehrheit der typischen Fragen sofort zu beantworten und das Maximum an häufigen Missverständnissen zu widerlegen. Anschließend ist es in einer schwierigen Situation möglich, mit einem Link abzuschlagen. Also lass uns gehen.
Die Grundlagen
Webkomponenten sind eine Reihe moderner Spezifikationen, die aus den folgenden Grundelementen bestehen:
Benutzerdefinierte Elemente - Eine native Möglichkeit, eigene HTML-Tags mit dem angegebenen Verhalten, Erscheinungsbild und Ihrem eigenen internen Markup zu erstellen.
Shadow DOM - Trennung der internen Struktur der Komponente mit Kapselung der internen Stile und des restlichen Teils des Dokuments.
Vorlage - ein spezielles Tag, mit dem Sie Markup-Teile speichern, anwenden und bei Bedarf wiederverwenden können.
HTML-Importe - Die Möglichkeit, HTML-Blöcke zu importieren, die in anderen HTML-Dateien gespeichert sind
Das Gericht von all dem kann mit nativen CSS-Variablen, nativen ES-Modulen und HTTP / 2-Server-Push gewürzt werden. Es gibt auch Slots, benutzerdefinierte Attribute, benutzerdefinierte Ereignisse und andere Details. Über sie etwas später, wenn wir weiter üben.
Ja, Ihre Webkomponenten werden fast nirgendwo unterstützt.
Trockene Zahlen sind die besten Freunde eines Ingenieurs. Schauen wir uns aus diesem Blickwinkel „fast nirgendwo“ an:
Benutzerdefinierte Elemente - 78,71%
Schatten-DOM - 79,12%
Vorlage - 89,61%
HTML-Importe - 69,16%
Wie wir sehen können, funktionieren die oben genannten Technologien in Browsern für die überwiegende Mehrheit der Benutzer. HTML-Importe verderben das Bild ein wenig, aber wir sind nicht verpflichtet, den gesamten Satz zu verwenden (ich bevorzuge native ES-Module, um alles in praktische Blöcke zu unterteilen), auch einzeln finden Sie in dieser Liste viele „leckere“ Dinge.
Ich empfehle dringend, mir nicht blind zu vertrauen, sondern den angegebenen Links zu folgen. Dort sehen Sie beispielsweise den aktuellen Status dieser Spezifikationen und die Tatsache, dass benutzerdefinierte Elemente und Shadow DOM
ab Version 63 in Firefox volle Unterstützung erhalten haben . Wenn der Großteil der Fuchsbenutzer auf diese Version upgraden wird und dieser Moment gleich um die Ecke ist, werden die Gesamtzahlen noch attraktiver. Möglicherweise haben Sie auch die „unvollständige Unterstützung“ von benutzerdefinierten Elementen und Shadow DOM in Safari bemerkt. Mit einem Apple-Browser können Sie Ihre Komponente nicht von einem integrierten nativen Browserelement wie einer Schaltfläche, einer Auswahl und dergleichen erben. Safari hat auch einige Nuancen in CSS-Selektoren, wenn das Shadow DOM verwendet wird. In der Praxis ist es durchaus möglich, damit zu leben und nicht zu trauern. Anscheinend ist Microsoft Edge traditionell ein Außenseiter unter den modernen Browsern. Die Entwickler behaupten, dass Support implementiert wird. Wir warten.
Was tun mit dem Rest ~ 20% der Benutzer?
Polyfiles können verwendet werden, um diese Leute zu unterstützen. Ja, bei Polyphilen funktioniert es etwas langsamer, dies ist jedoch mit bloßem Auge nicht erkennbar. Aber für alle anderen wird es schneller gehen.
Wir haben vor fünf Jahren versucht, ein Projekt über Polymer durchzuführen. Alles war furchtbar langsam.
In diesen "fernen" Zeiten tobte der Entwurf des Standards (v0), dessen Unterstützung nur in Chrome implementiert wurde. Seitdem hat sich viel geändert: Eine neue Version des Standards, Version 1, wurde übernommen, native Unterstützung wurde in verschiedenen Browsern implementiert, Polyphile wurden neu geschrieben und bewährte Verfahren wurden bis zur Abwicklung eingeführt. Polymer selbst hat sich von einer technologischen Vorschau zu einer vollständig funktionierenden Lösung entwickelt, mit der man gut umgehen kann.
Einige Polymere ... Worum geht es?
Polymer ist eine Bibliothek zum Erstellen von Webkomponenten. Es implementiert Unterstützung für all den „Zucker“, an den wir bei der Arbeit mit gängigen Front-End-Frameworks so gewöhnt sind: dynamische Datenbindungen, Repeater für die Arbeit mit Arrays usw. Derzeit ist bereits die 3. stabile Version veröffentlicht diese Bibliothek. Die Entwicklung erfolgt unter aktiver Beteiligung von Chrome-Entwicklern. Das Ökosystem wird von Google gepflegt.
Die Gesamtlänge der Bärte der Entwickler beträgt ...Wann werden Webkomponenten verwendet?
Wenn Sie eine universelle gemeinsam genutzte Bibliothek von UI-Komponenten benötigen. Ein Fall im Leben: Ein Projekt, bei dem die Hauptanwendung in React und das Backoffice in Angular geschrieben ist. Und ich möchte die Gleichheit und alle Arten der Wiederverwendung der Codebasis. Und Webkomponenten fühlen sich
in verschiedenen Ökosystemen großartig
an .
Wenn Sie dem Design im Browser-Ansatz nahe sind . Sie können ohne ständige Neuerstellung der Anwendung und ohne unnötige Abhängigkeiten erstellen. Dies macht das Prototyping zu einer sehr angenehmen Erfahrung und ermöglicht es Ihrer Anwendung, sich reibungslos vom Prototypstatus zum Status der Produktionsversion zu entwickeln. Ich liebe das.
Wenn Ihnen das gute alte OOP gefällt : Erstellen Sie eine Klasse, indem Sie von einem HTML-Element erben, implementieren Sie die gewünschten Funktionen und Brötchen darin und erben Sie dann Klassen für spezielle Komponenten davon. Und jetzt haben Sie Ihr eigenes Mikroframework. Schönheit!
Wenn Sie BEM hassen : Shadow DOM isoliert Komponentenstile. Es ist weder eine mehrstöckige monströse Benennung noch eine Navigation zu Deklarationen in einem gemeinsamen CSS-Heap erforderlich. Alles ist kompakt in einer Komponente verpackt: Stile, Layout, Logik.
Wenn Sie Anwendungen entwickeln, die auf Electron basieren. Die aktuelle Version von Chromium in Electron unterstützt bereits alles, was Sie benötigen. Trotz der allgemeinen Verzögerung in den Versionen.
Wenn Sie Ihr Framework / Ihre Bibliothek schreiben möchten. Webkomponenten sind eine hervorragende kompositorische Grundlage für solche Experimente.
Wenn Sie einen hybriden Ansatz benötigen: Sie implementieren klassische Webseiten mit SPA-Elementen : Benutzerdefinierte Tags können mit jeder Servervorlagen-Engine verwendet werden. Sie können nur Teil des allgemeinen Markups sein und Ihren Zweck zum richtigen Zeitpunkt festlegen. Sie können ein ausgewogenes Verhältnis zwischen dem, was auf dem Server gerendert wird und dem, was auf dem Client funktioniert, aufrechterhalten.
Wenn Ihre Benutzer moderne Browser verwenden. Selbstverständlich.
Wenn Sie PWA entwickeln : Die wichtigsten mobilen Plattformen unterstützen alles sofort. Für einen schnellen Start gibt es ein
pwa-Starter-Kit .
Wenn Sie an einer erhöhten Anwendungssicherheit interessiert sind und eine detaillierte Abhängigkeitsprüfung für Sie unerschwinglich ist. Hier ist alles einfach: weniger Abhängigkeiten - weniger unkontrollierte Löcher.
Wenn Sie ein verrückter Optimierer sind und gerne mit der DOM-API arbeiten : Webkomponenten sind Teil der DOM-API mit allen Standardfunktionen gewöhnlicher DOM-Elemente.
Wenn Sie sich über die Abwärtskompatibilität von Bibliotheksversionen Gedanken gemacht haben : Wenn alles auf dem Hardcore-Standard basiert, ist es irgendwie zuverlässiger.
Wenn Sie KEINE Webkomponenten verwenden sollten
Wenn die Anforderungen für Ihr Projekt erfüllt sind, müssen alte und exotische Browser unterstützt werden. In diesem Fall werden Sie im Allgemeinen nicht beneidet. Mein Beileid.
Wenn Sie einfache Produkte mit einem kurzen Lebenszyklus entwickeln und keine einzige Codebasis entwickeln müssen.Wenn Sie hauptsächlich mit einem Legacy-Code arbeiten.Wenn Sie und Ihre Kollegen nur etwas Modisches verwenden und nichts anderes wissen wollen.Warum brauche ich das alles? Ich habe React / Vue / Angular / etc, genug für mich ...
Dann kann ein wesentlicher Teil dessen, was JavaScript in gängigen Bibliotheken und Frameworks tut, auf eine untergeordnete Browserimplementierung verlagert werden. Aus Gründen der Geschwindigkeit wird die exorbitante Anzahl von Abhängigkeiten und die Abhängigkeit von Abhängigkeiten verringert. Um des Guten willen.