Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Presentation — Web Components

Heute — ohne Web Components

Content

<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 -->

Notes

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).

Beispiele der CTA Button States

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.

Web Components — Definition

Content

MDN web docs

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.

Notes

(next Slide) ... aber was heisst das nun genau?

Web Components — Konzept

Content

Welche Probleme lösen Web Components?

  • Abstraktion
  • Code Reusability
  • Kapselung (keine äusseren Einflüsse)

Wie wird dies gelöst?

  1. Custom Elements
  2. Shadow DOM
  3. HTML templates / slots

Notes

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.

Web Components — Anwendung

Content

<script src="https://cdn.app.sbb.ch/base/14.1.1/wc/sbb-ds.js"/>
<sbb-cta text="Verbindung suchen"></sbb-cta>

Notes

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).

Content

Ohne 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 -->

Mit Web Components

<script src="https://cdn.app.sbb.ch/base/14.1.1/wc/sbb-ds.js"/>
<sbb-cta text="Verbindung suchen"></sbb-cta>

Notes

Web Components — Merkmale

Content

  • Benutzerdefinierte, wiederverwendbare Elemente
  • Gekapselte Funktionalität / Styling

Notes

Wie zeichnen sich Web Components aus?

Bisherige Schwierigkeiten

Content

  • Accessibility (a11y)
  • server side rendering (SSR) von Web Components

Notes

Mögliche Risiken die Web Components mit sich bringen

Content

  • 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

Notes

  • 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.

Web Components — Chancen

Content

  • 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

Notes

Wer setzt auf Web Components?

Content

Company Name in production OSS
Google Lit / Youtube ✔️ ✔️
SAP Open UI5 ✔️ ✔️
Salesforce Lightning Web Components (LWC) ✔️ ✔️
Apple Apple Music ✔️
IBM Carbon Custom Elements ✔️
Firefox Firefox UI ✔️ ✔️

Notes

  • 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

Wie werden Web Components am effizientesten eingesetzt?

Content

Sie sind die ideale als Basis für ein Design System (DS)

Company Name in production OSS
IBM Carbon ✔️ ✔️
Microsoft Fast ✔️ ✔️
Google Material ✔️ ✔️
GitLab Slippers ✔️ ✔️
SAP Open UI5 ✔️ ✔️
Salesforce Lightning Web Components (LWC) ✔️ ✔️
Ionic Ionic Framework ✔️ ✔️
LocalTapiola / Turva Duet
Swisscom SDX ✔️ ✔️
Telekom Scale ✔️ ✔️

Notes

Was ist das ideale Anwendungsgebiet von Web Components?

Fragestellungen / Herausforderungen März 2019 (vor PoC)

Content

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

Notes

Rückblick Web Components 2019

Content

  1. PoC Web Component
  2. Tablet Automat
  3. DCS

Notes

Was lief alles im Rahmen / unter Berücksichtigung von Web Components im 2019.

PoC Web Components — Erste Tuchfühlung

Content

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)

Notes

Tablet Automat — Prototyp

Content

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

Notes

DCS — Headless Shop Implementation die sich als mehr entpuppte

Content

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

Notes

Fragestellungen / Herausforderungen Dezember 2019

Content

  • 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)

Notes

Ist die Zeit reif für Web Components?

Content

Ja, jetzt ist der richtige Zeitpunkt um auf Web Components zu setzen — Konsens des SBB.ch Frontend Teams.

Notes

Wir nehmen das Ganze mit viel Zuversicht in Angriff.

Design System (DS) — Definition

Content

Was ist ein Design System?

  • 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)

Was beinhaltet denn nun ein Design System?

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.

Notes

Design System Team (interdisziplinär)

Content

Wir sehen folgende Rollen:

  • Product Owner
  • Frontend Engineer
  • Backend Engineer
  • UX
  • Operations / Dev Ops (Node, Build Pipeline, Monitoring)
  • "Kommunikator" / Requirement Engineer

Notes

Design System Aufbau (Schätzung)

Content

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

Notes

Design System Betrieb (Schätzung)

Content

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

Notes

Produkt Impact

Content

Was heisst dies für die verschiedenen Produkte

  • SBB.ch
    • wenig Features / Entwicklung in Q1 / Q2
  • DCS
    • Umsetzungen ab Q3 möglich auf der neuen Basis des Design Systems
  • Vega

Notes

Vorteile / Nachteile

Content

Vorteile

  • 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

Nachteile

... evtl. hier Risiken auflisten

Notes

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.

Roadmap 2020

Content

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.

Notes

(DITCHED SLIDE) Weiteres Vorgehen

Content

  • 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

Notes

(DITCHED SLIDE) Was wird zum Aufbau der Component Library benötigt?

Content

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

Was wird zum Betrieb der Component Library benötigt?

Notes

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.

(DITCHED SLIDE) Was heisst dies für uns?

Content

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

Notes

(DITCHED SLIDE) Stand / Wo stehen wir heute

Content

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

Notes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment