- SBB heute — ohne Web Components
- Web Components — Definition
- Web Components — Konzept
- Web Components — Anwendung
- Web Components — Merkmale
- Bisherige Schwierigkeiten
- Mögliche Risiken die Web Components mit sich bringen
- Web Components — Chancen
- Wer setzt auf Web Components?
- Wie werden Web Components eingesetzt / Anwendungsgebiet?
-
-
Save caillou/8fd66e530e2d49629fe5c7e24b01e3ff to your computer and use it in GitHub Desktop.
<div class="mod_group mod_timetable_input_form_buttonwrapper" data-timetableInputForm="button_wrapper">
<button type="submit" class="text__primarybutton button">
<svg focusable="false" class="mod_svgsprite_icon var_cta_arrow">
<use xlink:href="#SBB_08_arrow_down"/>
</svg>
Verbindung suchen
<svg focusable="false" class="mod_svgsprite_icon var_cta_arrow">
<use xlink:href="#SBB_08_arrow_down"/>
</svg>
</button>
</div>
<!-- dazu kommen Referenzen zu CSS Files sowie SVG Sprites -->
Was sehen wir hier?
Ich gehe davon aus, dass alle bereits ein wenig HTML gesehen haben? Dieses Markup beschreibt wie ein Button auf SBB.ch aussieht. In diesem konkreten Fall beschreibt es den Button für das Absenden der Fahrplanabfrage.
Dazu kämen ebenfalls Referenzen zu CSS Files (die für die Darstellung zuständig sind) sowie SVG Sprites (die die Icons beinhalten) ...
- je nach Modul auch JavaScript Abhänigkeiten (und in diesem Fall weitere Abhängigkeiten zu jQuery)
All dies muss berücksichtigt werden, wenn heutzutage Markup vom Backend eingepflegt / aktualisiert wird.
Für die damalige Zeit war dies der modularste Ansatz, heute gibt es jedoch andere Lösungen.
Webkomponenten sind eine Gruppe von Web-Technologien, die es ermöglichen, benutzerdefinierte, wiederverwendbare HTML Elemente zu erstellen, deren Funktionalität gekapselt ist und damit vollständig getrennt von anderem Code.
(next Slide) ... aber was heisst das nun genau?
Welche Probleme lösen Web Components?
- Abstraktion
- Code Reusability
- Kapselung (keine äusseren Einflüsse)
Wie wird dies gelöst?
- Custom Elements
- Shadow DOM
- HTML templates / slots
<sbb-cta-button type="submit">
Verbindung suchen
</sbb-cta-button>
Welche Probleme lösen Web Components?
DRY (Do Not Repeat Yourself) ist eine goldene Regel der Softwareentwicklung. Code sollte möglichst wiederverwendet werden. Für HTML / CSS / JS ist dies (bisher) nicht so einfach. Eben vorhin haben wir gesehen, was alles nötig ist, um ein Custom UI-Element zu erstellen (Beispiel CTA Button).
Zum andern sollten Implementationsdetails einer API für die Nutzer der API nicht ersichtlich sein. Z.b. wollen wir beim nutzen einer Rest API keine DB spezifischen Konfigurationen vornehmen. Das selbe sollte für unser Frontend gelten. Heute muss man zum Beispiel im Button ein SVG mitgeben.
Kommt die Button Komponente an mehreren Orten zum Einsatz, muss diese dementsprechend an mehreren Orten gepflegt und gewartet werden. Passen wir unsere Implementation an, e.g. ein Wechsel von SVG auf Canvas, müssen alle Bezüger des Buttons ihren Code anpassen (AEM, Fahrplan, Webshop, …). Breaking Changes kommen oft vor. Oder es wird von möglichen Verbesserungen abgesehen, da diese für die Bezüger einen erheblichen mehraufand bedeuten.
Weiter besteht die Möglichkeit, dass das Styling (CSS) unserer Komponenten von den beziehenden Seiten überschrieben wird.
Web Components bieten für diese Probleme eine einheitliche und standardisierte Lösung.
Wie wird dies gelöst?
Mittels drei Haupttechnologien die gemeinsam (oder einzeln) verwendet werden können.
- Custom Elements (Benutzerdefinierte Elemente): Eine JavaScript API, die es ermöglicht, benutzerdefinierte Elemente sowie deren Verhalten zu definieren.
- Shadow DOM: Eine JavaScript API, welche HTML Elemente und deren Styles vom Rest der Applikation abkapselt. Das Shadow DOM wird unabhängig des DOMs des Hauptdokuments gerendert. Mit Hilfe dieser Technologie verbleiben die Ausprägungen solcher Elemente privat. Skripte und Styles innerhalb des Shadow DOM können nicht mit anderen Teilen des Dokuments kollidieren.
- HTML-Templates / Slots: Die
<template>
- und<slot>
-Elemente gestatten es, Markup-Vorlagen zu schreiben, die nicht auf der dargestellten Seite abgebildet werden. Diese können dann als Grundlage für benutzerdefinierte Elemente mehrere Male wiederverwendet werden.
<script src="https://cdn.app.sbb.ch/base/14.1.1/wc/sbb-ds.js"/>
<sbb-cta text="Verbindung suchen"></sbb-cta>
Ich möchte dies noch einmal anhand eines Beispiels kurz erläutern. Keine Bange, dies ist das letzte Code Snippet, welches ich hier heute zeige.
Was sehen wir nun hier?
- Ein neues Tag,
<sbb-cta>
, welches im HTML Standard nicht existiert. Mittels eines Custom Elements wurde dieses definiert, und es ist nun dem Browser bekannt. - Einen JavaScript Quellcode, der das Aussehen und die Funktionalität des Elements definiert.
Mit den folgenden zwei Zeilen Code ist man also in der Lage einen benutzerdefinierten Call to Action Button
, mit einem einheitlichen Design und Verhalten projektübergreifend / unternehmensweit zu nutzen.
Das Styling des Buttons kann nicht von aussen beeinflusst wird und ist in sich geschlossen (Komponenten Architektur).
- Die Web Componts sind ein single point of failure.
- JavaScript ist notwenig, wenn kein SSR vorhanden ist.
- Single point of failure
- Der Vorteil der Zentralisierung bringt auch Risiken mit sich. Das heisst, es muss gewährleistet werden, dass die Komponenten stets gemonitored / getracked (Error Tracking) werden.
- Dies ist aber insofern schon heute der Fall, da unsere Komponenten in einem einzelenen File ausgeleifert werden.
- JavaScript notwenig wenn Web Components nicht auf dem Server gerendert werden. Auch dies ist bei den meisten unserer Komponenten schon jetzt der Fall.
-
Framework / Plattform agnostisch
-
Offener Standard
-
Future Proof
-
Portabilität
-
Einfachere Handhabung
-
Einfachere Wartbarkeit der Komponente
-
Monitoring / Tracking der Komponenten
-
Framework / Plattform agnostisch (keine Abhängigkeiten, One framework, any platform)
-
offener Standard (basiert auf Standard Web Technologien)
-
Future Proof (da ein Web Standard)
-
Portabilität (einfache Integration in bestehende Systeme)
-
einfachere Handhabung (daraus resultieren weniger Bugs)
-
einfachere Wartbarkeit der Komponente (zentralisierte Entwicklung / Wartung / Erweiterung / Deployment / Update)
-
Monitoring / Tracking der Komponenten (Auswertung welche Komponenten effektiv wo / wieviel genutzt werden)
Company | Name | in production | OSS |
---|---|---|---|
Lit | ✔️ | ✔️ | |
SAP | Open UI5 | ✔️ | ✔️ |
Salesforce | Lightning Web Components (LWC) | ✔️ | ✔️ |
Apple | Apple Music | ✔️ | ✗ |
IBM | Carbon Custom Elements | ✗ | ✔️ |
Firefox | Firefox UI der gesammten Applikation | ✔️ | ✔️ |
- Abgesehen von Apple sind alle Web Component Libraries / Framework Open Source (OSS)
- und alle aussert Caron Custom Elementes von IBM werden bereits produktiv verwendet