- 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?
- 2019 Review
- Ist die Zeit reif für Web Components?
- Design System
- Vorteile / Nachteile
Last active
May 9, 2021 22:30
-
-
Save 4aficiona2/f32dd67a8198b335fd7cadd641f019c2 to your computer and use it in GitHub Desktop.
Presentation — Web Components
<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 -->Anschaungsbeispiel eines kleinen / einfachen Moduls heute auf SBB.ch.
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 (siehe nachfolgend).
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ängigkeiten (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
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).
Des Weiteren 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. Dasselbe 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, z.B. 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): Sind JavaScript APIs, die es ermöglichen, benutzerdefinierte Elemente sowie deren Verhalten zu definieren.
- Shadow DOM: Sind ebenfalls JavaScript APIs, um einen Baum aus darin gekapselten Shadow-DOM-Elementen an ein Element anzufügen, der unabhängig vom DOM des Hauptdokuments gerendert wird, sowie um die dazugehörige Funktionalität zu steuern. Mit Hilfe dieser Technologie verbleiben die Ausprägungen solcher Elemente privat, sodass Skripte und Styles auf sie angewendet werden können, ohne dass sie mit anderen Teilen des Dokuments kollidieren.
- HTML-Templates / Slots: Die - und -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?
- zum Einen ein neues Tag
<sbb-cta>welches im HTML Standard so natürlich nicht existiert, aber wir mittels einem Custom Element definieren können - zum Anderen sehen wir die Quelle (JavaScript File), die das Aussehen und die Funktionalität / das Verhalten 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
Dabei kommt dazu, dass das Styling nicht von aussen beeinflusst wird und in sich geschlossen ist (Komponenten Architektur).
<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 --><script src="https://cdn.app.sbb.ch/base/14.1.1/wc/sbb-ds.js"/>
<sbb-cta text="Verbindung suchen"></sbb-cta>- Single point of failure
- Der Vorteil der Zentralisierung bringt auch Risiken mit sich
- JavaScript notwendig wenn Web Components nicht auf dem Server gerendert werden
- schon heute zu einem gewissen Teil der Fall
- Serverside Rendering (SSR)
- Noch relativ wenig Referenzmaterial zur Verfügung — viel muss selber erarbeitet werden
- Know-how bei Entwicklern ist noch nicht weit verbreitet
- Potentieller organisatorischer Flaschenhals (Web Component Library-Team)
- Abhängigkeit zu Stencil als Abstraktion (Web Component Library).
- Potential für falsche Anwendung besteht nach wie vor (Web Component Library).
- Potential für Performance Impact
- Wenn Web Component Library nicht korrekt bezogen wird (z.B. selber hosten mit http1.1 und keinen Caching Headers)
- Potentiell höhere Caching Komplexität in PWA (JSON-Antworten)
- Klassische Web Crawler könnten Probleme bei der Indexierung haben
- 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.
- 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
- Keine Abhängigkeiten, One framework, any platform
-
Offener Standard (Potential für Hybrid-Apps)
- 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
-
Potentiell verbessertes Caching
- Wenn verschiedene Applikationen dieselbe Version vom selben Ort beziehen
| Company | Name | in production | OSS |
|---|---|---|---|
| Lit / Youtube | ✔️ | ✔️ | |
| SAP | Open UI5 | ✔️ | ✔️ |
| Salesforce | Lightning Web Components (LWC) | ✔️ | ✔️ |
| Apple | Apple Music | ✔️ | ✗ |
| IBM | Carbon Custom Elements | ✗ | ✔️ |
| Firefox | Firefox UI | ✔️ | ✔️ |
- Abgesehen von Apple sind alle Web Component Libraries / Framework Open Source (OSS)
- und alle aussert Caron Custom Elementes von IBM werden bereits produktiv verwendet
- Firefox UI -> gesammte Applikation
Sie sind die ideale als Basis für ein Design System (DS)
| Company | Name | in production | OSS |
|---|---|---|---|
| IBM | Carbon | ✔️ | ✔️ |
| Microsoft | Fast | ✔️ | ✔️ |
| Material | ✔️ | ✔️ | |
| GitLab | Slippers | ✔️ | ✔️ |
| SAP | Open UI5 | ✔️ | ✔️ |
| Salesforce | Lightning Web Components (LWC) | ✔️ | ✔️ |
| Ionic | Ionic Framework | ✔️ | ✔️ |
| LocalTapiola / Turva | Duet | ✗ | ✗ |
| Swisscom | SDX | ✔️ | ✔️ |
| Telekom | Scale | ✔️ | ✔️ |
Was ist das ideale Anwendungsgebiet von Web Components?
zu Web Components
- Wie wird sich die Technology entwicklen
- Wie wird die Adaption von Web Components sein
- Wie funktionieren Web Components genau
- Was gibt es für Frameworks / Abstrationen
- Intergationsmöglichkeiten in die bekannten Frameworks
- Browser Support
- SEO
- Accessibility
- Performance
Scope
- Teameffort (Frontend) während eines Sprints
- Überblick über Technologie und Verwendbarkeit von Web Components gewinnen
- Einmalige Verwendung während PoC
Outcome
- Rund 50 Web Component Artefakte erstellt mit Stencil
- Integration der Web Components in Anwendungsframework (React-, Vue-, Angular Components)
Scope
- 1 Person (Frontend)
- Entwicklung einer Single Page Application (SPA)
Outcome
-
Umgesetzt mit Stencil (Components sowie App) und Redux
-
Explizit umgesetzt für die Verwendung in Chromium, andere Browser wurden nicht berücksichtigt
-
Explizit entwickelt für zwei Viewports
-
Accessibility (a11y) wurde explizit vernachlässigt
-
Wegen der von Anfang an gesetzten Einschränkungen können die erstellten Webcomponents nicht ohne Weiteres in anderen Kanälen (z.B. Webshop) eingesetzt werden
-
Für die Ansprüche des Billetautomaten ist die App aus Sicht Frontend quasi produktionsreif
-
Vereinfachtes Setup
- Komponenten und App wurden im selben Projekt erstellt
- Kein Preview der Komponenten
- Komponenten wurden nicht auf npm o.ä. veröffentlicht
-
Präsentation am Digitaltag / anderen internen SBB Veranstaltungen mit viel positivem Feedback / hohe Resonanz
Scope
- 1 Person (Frontend)
- Research & Entwicklung eines produktiven Magento Headless Shops basierend auf wiederverwendbaren Web Components
Outcome
- Analyse von Headless Magento Lösungen
- PoC Vue Storefront / Storefront UI Ecosystem
- Portierung / Migrierung der Stencil Web Components (PoC Web Components) auf Stencil One (Major Release)
- Kontinuierliche Updates des Stencil Web Components PoCs
- PoC Pre Rendering von Web Components mit Stencil (prerender output target)
- Testing Magento REST API
- Testing Magento GraphQL (ab Anfang Sept. möglich)
- Aufbau GraphQL Knowhow
- PoC Nuxt – Rendering Web Components in Nuxt (CSR)
- Aufbau Nuxt / Vue Knowhow
- PoC Nuxt / Apollo Client – GraphQL Magento Anbindung mittels Apollo Client
- Kontinuierlicher Austausch mit Stencil Core Team / (Web Component) Community (SSR)
- PoC Nuxt – Rendering Web Components in Nuxt (SSR)
- Aufgrund der harzigen / ungewissen SSR Implementation von Web Components verlagerte sich der Fokus auf den zweiten Teil der Web Component Library. Auf den Zeitpunkt vor der Erstellung (sowie des Betriebs der Komponenten Library)
- Component Browser Integration (Storybook)
- Analyse Design System Space
- Design System API / Design Tokens / Dokumentation des DS / Feedback Loops / Austausch UX / PO / Component Testing
- ...
- Bei all dem war stets die Developer Experience (DX), die Zusammenarbeit, die Wartbarkeit, Skalierung, Performance und Machbarkeit im Fokus
- Wie wird sich die Technology entwicklen
- Wie wird die Adaption von Web Components sein
- Wie funktionieren Web Components genau
- Was gibt es für Frameworks / Abstrationen
- Intergationsmöglichkeiten in die bekannten Frameworks
- Browser Support
- SEO
- Accessibility
- Performance
- SSR
- Testing Framework (Stencil)
- Component Browser / Component Preview
- Headless Magento (neu)
- GraphQL / Apollo Client (neu)
- Nuxt / Vue (neu)
- SSR (context-spezifisch z.B. in Nuxt / generisch)
- Tracking
- Zusammenspiel Adobe Target (nicht erfüllt gemäss Backend)
- Security (neu)
- Node Plattform Infrastruktur / Betrieb (neu)
- Teams / Zusammenarbeit (neu)
- Lead / Organisation (neu)
- Frontend Setup / Architektur (neu)
- Design Systems / Design System API / Design Tokens (neu)
- Systematisches Denken über Design
- Eine geteilte Sprache / ein geteiltes Vokabular
- Flexibles, modulares System welches sich anpassen lässt / Teile ausgetauscht werden können (kein Tool / Vendor Lock-In)
Bei dieser Frage gehen die Meinungen bereits auseinander und es ist nicht klar definiert, was alles zu einem Design System gehört und was nicht. Aber man sollte wohl die folgenden Punkte miteinbeziehen.
- Einheitliche Sprache / Namenskonventionen
- Design Tokens (single source of truth)
- Design System / Token API
- Ideation / Creation Tools
- Component Library
- Component Browser
- Design System Utilities / Helper
- Accessibility / Optimization / Performance / Visual Regression Testing Tools (Build time)
- Accessibility / Visual Testing (QA, z.B. Chroma)
- Dokumentation
- Tokens
- Components
- Gebrauch
- Anwendung / Integration
- ...
zwingende organisatorische Aspekte
- Muss betreut und weiterentwickelt werden
- Ansprechspersonen haben / Kanäle definieren
Was klar ist, ist das Web Components die ideale Basis eines Design Systems sind / sich in ein Design System einfügen — dies sehen nicht ganz unwesentliche Unternehmen (IBM, Ionic, Google, ...) ebenso und haben ein Bestreben dies zu ändern falls dem nicht bereits so wäre.
Für die Erstellung des Duet Design System wurden gemäss ihren eigenen Angaben 4 FTE über 6 Monate benötiget.
Daraus leiten wir die folgenden Ressourcenangaben für den Aufbau ab: 6 FTE über 6 Monate
| Rolle | FTE | Beschreibung |
|---|---|---|
| Product Owner | 0.5 | |
| Frontend Engineer | 3 | |
| Backend Engineer | 0.5 | |
| UX | 1 | |
| Operations / Dev Ops | 0.5 | Node, Build Pipeline, Monitoring |
| "Kommunikator" / Requirement Engineer | 0.5 |
Der Betrieb umfasst folgende Tasks:
- PR Review
- CI / CD Pipeline
- Monitoring Analytics
- Monitoring der laufenden Systeme (System Level)
- Error Tracking Komponenten
- QA
- Backlog (Bug Tracking, Feature Requests, Improvements)
- Dokumentation
- Kommunikation
- Maintainance Build System (Stencil Setup)
- Maintainance Infrastruktur
- Gatekeeping Design / Component Patterns
- ...
4 FTE fortlaufend
| Rolle | FTE | Beschreibung |
|---|---|---|
| Product Owner | 0.5 | |
| Frontend Engineer | 1.5 | |
| Backend Engineer | 0.5 | |
| UX | 0.5 | |
| Operations / Dev Ops | 0.5 | Node, Build Pipeline, Monitoring |
| "Kommunikator" / Requirement Engineer | 0.5 |
-
Abbau technischer Schuld
-
Schnellere Entwicklungszyklen / einfachere Wartbarkeit der Komponente
- Aufgrund zentralisierter Entwicklung / Wartung / Erweiterung / Deployment / Update
-
Einfachere Handhabung
- Kleinere Fehleranfälligkeit
- Developer Experience (DX)
- Staffing
-
Portabilität
- Einfache Integration in bestehende Systeme
-
Qualitätssicherung
- Mittels Monitoring / Error Tracking der Komponenten
- Deploy with confidence
-
Effizienterer Austausch mit UX / PO / Stakeholder
-
Effektivere Feedback Loops
-
DX / UX Happiness
... evtl. hier Risiken auflisten
Mit zunehmender Verlagerung vom Backend ins Frontend kommen auch neue Bedürfnisse im Frontend auf.
Dies dient zum einen dem effizienteren Entwickeln der Anwendungen / Komponenten sowie der Qualitätssicherung der Anwendungen / Komponenten.
| Q1 | Q2 | Q3 | Q4 | |
|---|---|---|---|---|
| Design System | Team Building / Setup | Setup | Übergang Betrieb* | Betrieb* |
| WCMS | minimale Weiterentwicklung | minimale Weiterentwicklung | Betrieb | Betrieb |
| DCS | UX / IA Research | UX / IA Design | Umsetzung Features auf Web Component Basis | Umsetzung Features auf Web Component Basis |
'*' Betrieb der Plattform und keine Web Components Erstellung. Das Team unterstützt die Teams, die wiederum die Web Components / Features umsetzen.
- Für DCS wird auf Basis von Web Components ein neues Produkt-Feature (Gepäckaufgabe) umgesetzt
- diese Web Komponente kann nebst dem DCS Shop genauso auf SBB.ch oder im Webshop verwendet werden
- Parallel dazu wird die Komponenten Library (DS auf Web Component Basis) erstellt und ausgebaut
- Nach der Umsetzung des neuen Produkt-Features könnte eine weitere Beurteilung vorgenommen werden
Build Setup / Frontend Tooling
- Web Component Setup (Stencil)
- Component Browser Integration (Storybook)
- Test Setup (Visual Regression Testing)
Continuous Integration / Deployment Setup / Betrieb ()
- Monitoring
- Error Tracking
- Analyse
(Schätzung Aufwand: 20-40 PT)
Weiter sollte berücksichtigt werden:
Design System API / Design Token Integration
- effizienterer Austausch mit UX / PO / Stakeholder
- effektivere Feedback Loops
- DX / UX Happiness
==================== neuer Slide
Mit zunehmender Verlagerung vom Backend ins Frontend kommen auch neue Bedürfnisse im Frontend auf.
Dies dient zum einen dem effizienteren Entwickeln der Anwendungen / Komponenten sowie der Qualitaetssicherung der Anwendungen / Komponenten.
Hier gibt es 3 Bereiche
- SBB.ch
- Team Organistaion Frontend
- Frontend Setup / Architektur (Jan.)
- DCS
- UX / IA der bisherigen Site anschauen
- UX / IA des neu zu entwickelnden Produkt-Features (Gepäckabgabe) mit Frontend Team
- One Team
- Team Organistaion allgemein / Planung / Lead / Koordination
zu Web Components
- sehr positives Gefühl, dass Web Components die richtige technologische Basis ist (Stand Dez. 2019)
- Erfahrung in der Entwicklung von Web Components mit Stencil
- Stencil Setup für Web Component Library
- SSR Erfahrung / Überblick
- Component Browser / Component Preview Integration mit Stencil
- Erfahrungswerte mit der Architekur der Web Components / des Namings / der Versionierung
- Accessibility Rückhalt
- Component Browser / Component Preview
- keine einsatzfähige Web Komponente
andere Themen
- Erste Erfahrungen mit Headless CMSs (Magento)
- Erfahrungen mit GraphQL
- Erfahrungen Nuxt / Vue
- Überblick Frontend Architekur Landschaft
- Überblick Design System Landschaft
- Security
- Node Plattform Infrastruktur / Betrieb
- Design Systems / Design System API / Design Tokens
- Teams / Zusammenarbeit
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment