Component Library
- Component Library
- Frontend Engineering
- Backend (Node.js)
- Build- & Test-Pipelines
- Michael Zoidl
- Nico Weingärtner
- Silvana Zinngräbe
- Jonathan Häberle
- Jan Aman
- Benjamin Konopka
Ausgangslage
Jedes Tool von Null
Konfiguratoren, Dashboards und Tools für Produktion und Vertrieb laufen über Jahre und müssen einheitlich, wartbar und schnell erweiterbar bleiben. Ohne gemeinsame Basis wird jedes interne Werkzeug neu gedacht.
Eine gemeinsame Komponenten-Basis
Eine Component Library, die in mehreren internen Tools wiederverwendet wird, mit zentralen Build- und Test-Standards.
So funktioniert’s
- React-Komponente
- Storybook
- Storyshots
- GitHub Actions
- Interne Tools
Jede Komponente wird einmal gebaut, dokumentiert und visuell abgesichert und dann in mehreren internen Tools wiederverwendet.
Lösung
Library auf React-Hooks-Basis
Dokumentiert in Storybook, mit Storyshots als visuelle Regressionsabsicherung.
Apollo und GraphQL
Anbindung der Komponenten an die bestehenden Backends.
Eigene Webpack-Setups
Custom Compiler-Konfiguration für die Anforderungen der internen Tool-Landschaft: SASS, SVGO, Formik und Internationalisierung.
Backend in Node.js
Neue Endpunkte und Services dort, wo die Tools sie gebraucht haben.
Test-Umgebung und CI
Jest, Storyshots und GitHub Actions als sauberes Setup, damit Maintenance ohne Reibung möglich bleibt.
Übergeben und weitergeführt.
Nach Engagement-Ende haben interne Alps-Alpine-Teams die Component Library weitergeführt, weil das Setup von Anfang an auf Übergabe ausgelegt war. Als erstes größeres Engagement nach der alm-Gründung wurde es zur Vorlage für spätere Component-Library- und Design-System-Projekte wie badenova und NotarPartner.
Stack
-
React
- React Hooks
-
GraphQL
-
Apollo
- Webpack
- Babel
-
Jest
-
Storybook
- Storyshots
- SASS
- SVGO
-
Node.js
- Formik
-
GitHub Actions