Dies ist kein Tutorial oder eine vollständige Überprüfung, sondern heißblütige Notizen nach dem Kompilieren einer Komponentenbibliothek. Alles begann mit der üblichen Alltagsgeschichte: Es gibt einen Legacy-Code, Sie müssen Pipmochek und kleine Sticks am Legacy befestigen, Sie können nichts einmal umschreiben und hier nichts mit Ihren Händen berühren. Nur für den Fall, berühren Sie die großen und beängstigenden Pakete nicht. Warum nehmen Sie nicht einfach das beste
Vanilla JS- Framework und schreiben darauf, wie es Ihre Großväter hinterlassen haben?
Da das Arbeitsvolumen jedoch sehr auffällig sein sollte, erlebte aus irgendeinem Grund niemand kreative Impulse von der Idee, alles in bloßem JS zu schreiben. Wir haben uns die Werkzeuge angesehen und aus ihnen diejenigen ausgewählt, die die Verbraucher unserer Komponenten nicht vor zitternden Knien erschrecken würden.
Die Werkzeuge
Obwohl ich diesen ganzen Abschnitt bereits verwöhnt habe, muss hier etwas gesagt werden. Erstens wurden Webkomponenten sofort absolut unbestritten: Wenn das Ergebnis der Kreativität eine Bibliothek von Komponenten ist und Sie kein großes Monster a la Angular ziehen können, das sich vollständig vollständig modularisiert, bleibt nur, dass Sie den Bibliothekscode überhaupt nicht ziehen müssen. und funktioniert "einfach so" in modernen Browsern. Die Webkomponenten selbst sind immer noch das gleiche erstaunliche Vanilla JS-Framework mit nur wenigen gelösten Modularitätsproblemen. Es bleibt noch zu viel übrig, um mit eigenen Händen zu schreiben - Sie benötigen einen Wrapper mit Standardisierung, und es ist auch wünschenswert, dass für jede Komponente mindestens eine Boilerplate vorhanden ist.
Es gibt nicht viele solcher Wrapper und sie sind sogar ausgereift genug, um in einem ernsthaften
Produkt verwendet zu werden :
Hybrids, LitElement, Stencil. Und alle machen ungefähr dasselbe auf die gleiche Weise, der Unterschied liegt in den kleinen Dingen. Hybrids versucht, trendy und klassenlos zu sein, Stencil ist trendy und reaktionsartig, LitElement scheint sich nicht einmal anzustrengen. Und nach den Ergebnissen der Auswahl aus unbedeutenden Kleinigkeiten blieb LitElement am Ausgang - OOPshniki wandte sich von Hybrids und Nicht-Amateuren der Reaktion ab - von Stencil, in dem JSX im Allgemeinen eine Wiederholung der nicht unbestreitbarsten Ideen der Reaktion verspürte.
Zu kämpfen?
Es ist nicht so interessant, darüber zu sprechen, was Sie können, es steht alles in der Dokumentation, daher werde ich weiterhin hauptsächlich darüber sprechen, was Sie nicht können: Sie schreiben normalerweise nicht darüber in der Dokumentation.
Muster
In Bezug auf Vorlagen verwendet LitElement lit-html, was vollkommen minimalistisch ist:
const template = html` <div attr=${a} .property=${b} ?booleanAttr=${c} @click=${handleClick} ></div> `;
Dies ist kein HTML, aber Sie müssen sich hier genau drei Konstruktionen in einem Symbol merken - ".", "?" Und "@". Alles andere ist HTML. In Bezug auf JSX mit seinem Klassennamen und dem Rest ist es ein bisschen schöner und rechtlich vom JS / TS-Code getrennt. Übrigens folgt von hier aus das erste „Unmögliche“ - etwas Schreckliches zu binden funktioniert nicht, Sie können nur die Werte von Attributen und Eigenschaften sowie den Textinhalt binden. Natürlich gibt es keine Magie in markierten Vorlagenliteralen, und auf Kosten einer bestimmten Anzahl von Perversionen können Sie zur Laufzeit eine Zeichenfolge kompilieren und Lit-HTML-Ordner daran anhängen, aber dies wird tatsächlich mit Ihren Händen in den Render übertragen, und mit dem gleichen Erfolg können Sie Zeilen sammeln und senden in innerHTML. Dies geschieht normalerweise durch die Zusammenstellung von Vorlagen und die Aufteilung komplexer Komponenten in einfachere Komponenten. Die Boilerplate ist ziemlich klein - die Template-Bindung fehlt praktisch, da es sich nur um eine Variable handelt. Um eine Komponente zu erstellen, benötigen Sie fünf "zusätzliche" Zeilen.
Komponenten
Das einzige (aber signifikante) Problem der Komponenten besteht darin, dass Sie das Schatten-DOM benötigen, um die Komponenten vollständig mit dem Rendering der Kinder zu „mischen“. Was natürlich standardmäßig in LitElement enthalten ist und im Allgemeinen nicht schlecht zu sein scheint. Das Schatten-DOM hat derzeit ein großes Problem mit Stilen, ähnlich wie CSS-Module: Um Stile zu isolieren, werden sie perfekt isoliert, aber auf dem Weg dorthin wird die gesamte Kaskade reduziert. Es ist einfach unmöglich, von außen in isolierte Stile zu gelangen. Im Allgemeinen (fast) nichts.
Dies beeinträchtigt beispielsweise die Fähigkeit, Komponenten verschiedener Themen zu rollen, erheblich. Mit dem Schatten-DOM können Sie entweder alle Stiloptionen in die Komponente packen oder versuchen, das Thema vollständig von CSS-Variablen abhängig zu machen - dies ist das "Fast", mit dem Sie isolierte Stile zucken können. Aber mit denen es notwendig ist, Variablen buchstäblich für jede vernünftige Stilisierung bereitzustellen, und mit hoher Wahrscheinlichkeit wird es dann noch mehr hinzugefügt.
Glücklicherweise kann das Shadow DOM in LitElement einfach in der Komponente deaktiviert werden. Leider wird dadurch auch die Möglichkeit deaktiviert, untergeordnete Elemente des Elements an den richtigen Stellen der Vorlage über <Slot> anzuvisieren. Glücklicherweise können Sie, nachdem Sie ein wenig pervertiert haben, sowohl die erste als auch die zweite erhalten: Dazu müssen Sie
nur eine Schattenwurzel auf jeden erforderlichen Steckplatz legen und nichts außer <slot> darin haben. Somit ist die Stilisierung der Komponente offen und es sind Schlitze vorhanden. Ich wollte ein kurzes Beispiel geben, aber leider funktioniert der Code zum Bearbeiten von Slots sowieso nicht kurz - sehr interessierte Leute können
diese Ausgabe hier lesen
. Die Ideen von dort haben mich inspiriert.
Erwähnenswert ist auch, dass in absehbarer Zeit die Browserunterstützung und die Polyfills
:: part und :: theme wahrscheinlich sinken werden und mit ihnen das Schatten-DOM endlich zur Lösung wird, auf die alle seit vielen Jahren gewartet haben - so dass es isoliert ist und erweiterbar / veränderlich. Aber bisher ist das noch nicht da.
Bereitstellen
An diesem Punkt kommt das Schreiben über „was unmöglich ist“ nicht mehr heraus, da alles weiter entfernt werden kann - beleuchtete Bibliotheken existieren in Form von ES-Modulen und werden daher ohne Probleme von irgendetwas und auf irgendeine Weise aufgenommen (selbst mit einem nackten Browser, der Module handhaben kann) ) Für den Internet Explorer und den aktuellen Edge müssen Sie eine Polyfüllung von Webkomponenten verbinden. Für Module benötigen Sie etwas, das die Schmerzen beim Importieren von Browsern lindert, z. B.
es-module-shims , wenn Sie sie direkt aus dem Browser entfernen möchten
. Na ja, oder ein Bündler.
Die in die Anwendung eingebundenen Webkomponenten sind einfach und kitschig zu verwenden. Sie können sie in HTML verwenden und ihre Methoden und Eigenschaften im Code abrufen. Sie können hier sehen, wie gut dies alles mit einer anderen Bibliothek oder einem anderen Framework
verknüpft werden kann (die Reaktion war hervorragend, aber im Durchschnitt ist alles sehr gut). Wir haben uns an AngularJS festgehalten, und alles war banal: Mit ng-prop können Sie etwas auf die Komponente übertragen, und mit ng-on können Sie Ereignisse anhören.
Zusammenfassung
Wenn Sie eine Komponenten-Benutzeroberfläche erstellen und an etwas befestigen müssen, auf das Sie absolut nicht eingehen möchten (Legacy-Code, unmodernes, beängstigendes Framework und andere schlechte Stellen), helfen Webkomponenten einwandfrei. Die wichtigsten "ausgereiften" Bibliotheken, die mit ihnen verwaltet werden, sind klein, es gibt keine ernsthaften technischen Probleme hinsichtlich Modularität und Layout, und Sie können es einfach nehmen und tun. Welche Art von Bibliothek Sie nehmen - auch wenn dies nicht so wichtig ist, gibt es im Moment nur sehr wenige Unterschiede zwischen ihnen. Insbesondere das von uns getroffene LitElement hat kein einziges zusätzliches Problem für uns geschaffen und in allen Fällen in der erwarteten Weise funktioniert.