It’s #FrontendFriday – Verwendung von SCSS in nativen Web Components

05.08.2022

Hallo #FrontendFriday-Leser/in,

ihr wolltet schon immer wissen, wie die Verwendung von SCSS in einer in sich mit Shadow DOM abgeschotteten, nativen Web Component möglich ist, dann zieht euch auf jeden Fall diesen Beitrag rein.

Vorab ein kleiner Hinweis: ich gehe des Weiteren nicht explizit auf die detaillierte Beschreibung der Funktionsweise des Shadow DOM sowie der HTML Templates ein. Sondern beschränke mich erstmal nur auf die Custom Elements, der meiner Meinung nach wichtigsten JavaScript API im Zusammenhang mit Web Components.

Was sind Web Components?

Unter Web Components lässt sich eine schöne Analogie zu einem Werkzeugkasten schaffen. In einem Werkzeugkasten sind typischerweise Werkzeug drin, um bestimmte Projekte umzusetzen. Projiziert auf eine Web Component würde das Endergebnis ein oder mehrere benutzerdefinierte HTML Elemente sein, welche in Webapplikationen wiederverwendet werden können. Aber zurück zu unserem Werkzeugkasten. Was sind nun die Werkzeuge die uns zur Verfügung stehen? Die Antwort ist einfach: Custom Elements, Shadow DOM sowie HTML Templates.

  • Custom Elements: Hierbei handelt es sich um mehrere JavaScript API’s, welche die Erzeugung und Verwendung von DOM Elementen mit einem speziellen HTML Tag ermöglichen.
  • Shadow DOM: Sind mehrere JavaScript API’s, welche eine Verwendung eines eigenen, unabhängigen DOM möglich machen.
  • HTML Templates: Eine Erweiterung der gängigen HTML Spezifikation in der bestimmte HTML Inhalte zur Laufzeit instanziiert werden.

Was ist der größte Vorteil von nativen Web Components im Vergleich zu gängigen Frameworks sowie Bibliotheken?

Mit Frameworks und Bibliotheken wie React, Angular, Vue oder jQuery UI ist es möglich wiederverwendbare, mächtige Komponentenkonstrukte zu bauen. Übrigens die Kombination von Komponenten im DOM oder UI wird auch als Komponentenbaum bezeichnet. Aber zurück zu unseren mächtigen Komponenten. Jede Macht hat eine dunkle Seite, so auch die der Frameworks und Bibliotheken. Wir sind schlicht und einfach auf das jeweilige Framework gebunden. Bei nativen Web Componentens ist demgegenüber eine technologieunabhängige Wiederverwendung möglich. Cool oder?

In welchen Geschmacksrichtungen kommen die Custom Elements und was sind die Unterschiede?

Im Rahmen der Custom Elements Spezifikation stehen uns zwei Varianten zur Verfügung:

  • Erweiterte Standard Elemente: Als Vererbungsbasis dienen hier standardisierte HTML Elemente wie <button>, <intput>, <a>, usw.
  • Vollkommen unabhängige Elemente: Als Vererbungsbasis dient hier kein spezielles standardisiertes HTML Element, sondern die übergeordnete HTMLElement-Klasse.

Neben dem erwähnten Hauptunterschied gibt es noch weitere Unterschiede. Aber diese erspare ich euch an dieser Stelle.

Was sind Custom Element Reactions? Welche gibt es?

Hierbei handelt es sich um Callback-Methoden, welche in den verschiedenen Stadien eines Lebenszyklus eines Custom Elements vom Browser aufgerufen werden. Folgende Reactions stehen uns zur Verfügung: connectedCallaback(), attributeChangedCallback(), adoptedCallback() sowie diconnectCallback().

Wie können Custom Elements zusätzlich über die Reactions hinaus individualisiert werden?

Es ist im Rahmen der Custom Elements möglich sowohl standardisierte als auch nicht-standardisierte Attribute zu managen. Mit Management meine ich speziell das Initialisieren sowie Synchronisieren von Attributen. Das gleiche ist auch für Properties möglich. Den Unterschied zwischen Attributen und Properties im Rahmen des HTML Standards lass ich ebenfalls bewusst weg, denn es würde den Beitrag noch mehr aufblähen. Auch die Interaktion mit Events ist möglich. Hierbei ist ebenfalls eine Interaktion mit standardisierten als auch nicht-standardisierten Events möglich. Hinweis: Da auch vollkommen unabhängige Custom Elements von der HTMLElement-Klasse erben, steht bei diesen das Event Management System des DOM’s ebenfalls zur Verfügung.

Was ist im Zuge der Custom Elements und Events explizit betrachtet werden?

Event Listener konsumieren Ressourcen und sind bei einem nichtgebraucht stets zu entfernen. Dafür steht uns die disconnectCallback() Methode zur Verfügung.

Nun zur Preisfrage: Wie können wir SCSS in unseren Custom Elements verwenden und ist es überhaupt möglich?

Vorab, eine Nutzung von SCSS in Custom Elements ist prinzipiell möglich. Aber es ist externe Hilfe notwendig. Wir müssen uns eines weiteren NPM Pakets bedienen. „sass-to-string“ konvertiert unter der Haube SASS-Dateien zu JavaScript-Strings, welche wiederum JavaScript Module repräsentieren. Folgend ein Beispiel:

https://www.npmjs.com/package/sass-to-string

Dadurch kann über ein import-Statement das JavaScript Module zur Verfügung gestellt und weiterverwendet werden.

https://www.npmjs.com/package/sass-to-string

Es ist zu erwähnen, dass Webpack benötigt wird, um es sauber zu „bundeln“. Die dafür benötigte Konfiguration könnt ihr direkt aus dem NPM Paket entnehmen.

Fazit

Das Thema Web Components ist mittlerweile nicht mehr aus unserem Alltag wegzudenken. Gängige Frameworks sowie Bibliotheken leben uns dieses API’s basiertes Konstrukt jeden Tag aufs Neue vor. Mit dem „sass-to-string“ Paket haben wir nun ein weiteres Werkzeug in unser Komponentenbaukasten bekommen. Es benötigt zwar zusätzliches Setup im Webpack, aber der Aufwand lohnt sich…

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*