Die Weisen sagen: Veränderung ist unvermeidlich, Wachstum ist freiwillig. Wir bei djangsters mögen es zu wachsen. Deshalb entschieden wir uns im Zuge von Arbeiten an einer neuen Kundenhompage unsere Werkzeuge zu erweitern. Wir führen unter anderem Storybook ein und in diesem Beitrag wollten wir festhalten, was wir danach davon halten.
Aber zuerst müssen wir ein wenig über Storybook sprechen. Auf der Storybook-Seite wird es als Open-Source-Werkzeug für die isolierte Erstellung von UI-Komponenten und Seiten definiert. Sie sagen, dass es die Entwicklung, das Testen und die Dokumentation der Benutzeroberfläche vereinfacht.
Das bedeutet, dass du deine Komponenten erstellst und sie ansehen oder testen kannst, ohne dass ein komplettes System laufen muss. Dies ist weit entfernt von dem Versuch, eine neue Komponente zu erstellen, bei dem man das gesamte System, seine Abhängigkeiten usw. ausführen müsste, nur um die Änderungen zu sehen, die man vornimmt.
Wenn du deine Komponente erstellt hast, schreibst du eine sogenannte Story für sie. Eine Story ist im Grunde nur ein Bundle von Exporten, welche die angezeigten Zustände Ihrer Komponente definieren. Stories sind von den Komponenten getrennt und haben keinen Einfluss auf deine laufende Anwendung. Du kannst und solltest auch Stories für alle möglichen Zustände deiner Komponente schreiben. Das Schreiben von Stories würde den Rahmen dieses Beitrages sprengen, aber hier kannst du in englischer Sprache mehr darüber lesen.
Hier ist ein einfaches Beispiel, wie eine Story im Code aussieht:
Mit Storybook konnten wir nach anfänglichem Prozessschock unsere Produktivität und den Entwicklungsprozess verbessern. Es wurde auch von unseren Kunden gut angenommen, die anfangs verständlicherweise skeptisch waren, dass das Hinzufügen von mehr Funktionen irgendetwas verbessern würde. Schauen wir es uns also im Detail an.
Höhere Produktivität
Auf den ersten Blick scheint es widersprüchlich zu sein, dass das Hinzufügen eines zusätzlichen Schritts zum Entwicklungsprozess die Produktivität steigern würde, aber genau das haben wir erlebt. Die meisten der von uns erstellten Komponenten haben eine oder zwei begleitende Storys. Dadurch konnten wir den Kunden frühzeitig einbeziehen, und die Zeit zwischen den Iterationen war bemerkenswert kurz. Das Schreiben von Storys war relativ mühelos, und wir konnten es sogar noch beschleunigen, indem wir IDE-Vorlagen verwendeten, um Standard-Storys zu erstellen, die nur kleine Anpassungen und Aktualisierungen der Argumente erforderten.
Storybook ermöglichte es uns auch, gemeinsame Einstellungen, Viewpoints usw. für alle Stories global zu definieren. Dies erlaubte es uns, einfach zu testen, wie sich die Komponenten unter verschiedenen Breakpoints verhalten. Storybook war ziemlich genial, und die Kombination mit CSS-Modulen verhinderte weitestgehend Stylesheet-Kollisionen.
Verbessertes Testen
Storybook ermöglichte uns auch die Einführung von loki für visuelle Regressionstests. Visuelle Tests haben Vor- und Nachteile: Sie können viele unbeabsichtigte Änderungen abfangen, erhöhen aber z.B. auch die Wartungskosten. Aber dazu werden wir wahrscheinlich in einem anderen Beitrag mehr schreiben.
In unserem Fall fügten wir für jeden Breakpoint Loki-Tests für jede Komponente hinzu, wodurch wir schnell und einfach feststellen konnten, ob einige Komponenten miteinander kollidierten oder ob ein Teil des Codes unerwartete visuelle Änderungen mit sich brachte. Dies wirkte sich auch darauf aus, wie wir unsere Komponenten entwarfen und daraus resultierend führte es dazu, dass traditionelle Unit-Tests einfacher zu schreiben waren.
So wird die Story im Browser angezeigt, einschließlich interaktiver Komponentenelemente wie Popover.
Responsiveness
Bei der Entwicklung einer App, die von Millionen von Menschen auf verschiedenen Geräten genutzt werden soll, ist die Responsiveness besonders wichtig. Storybook ermöglichte es uns, unsere Ziel-Breakpoints zu definieren und schnell zwischen ihnen zu wechseln, was die Entwicklung erheblich beschleunigte. Loki ermöglichte es uns ebenfalls, diese Breakpoints zu bestimmen und unsere visuellen Tests auf Mobilgeräten, Tablets und Desktops mit einem einzigen Befehl laufen zu lassen.
Kompatibilität
Obwohl die Einrichtung trivial war, gab es einige Probleme, auf die wir gestoßen sind und die ich erwähnen sollte:
- Zunächst musst du sicherstellen, dass alle globalen Änderungen, die du an der App vornimmst, auch in Storybook vorgenommen werden. Dies bedeutet auch, dass du globale Styles zugunsten von Komponenten-Styles vermeiden solltest, wann immer dies möglich ist.
- Vergewissere dich, dass die App und Storybook die gleiche Version von Webpack verwenden, da es sonst zu Problemen kommen wird.
- MSW, was für Mock Service Worker steht, aber auch Magische-See-Weiden stehen könnte (das letzte Wort ist noch nicht gesprochen), ist dein Freund und macht das Testen von Komponenten, die APIs aufrufen, zu einem Kinderspiel.
Kundensicht
Wie bereits erwähnt, stand unser Kunde unserer Entscheidung für Storybook zunächst skeptisch gegenüber, aber das änderte sich, als wir ihm in Rekordzeit verschiedene Komponenten vorführen konnten. Sie konnten sehen, wie die neue Homepage aussah, und unser QA-Team konnte ganz einfach testen, ohne etwas über die Einrichtung des gesamten Systems wissen zu müssen.
Aus der Sicht des Kunden hat Storybook an sich den Entwicklungsprozess also nicht wesentlich verändert. Es ermöglichte ihm jedoch, die Änderungen frühzeitig zu sehen und den Schwerpunkt auf das visuelle Design zu legen.
Fazit
Alles in allem hatten wir mit Storybook eine bessere Zeit als ohne Storybook. Es steigerte unsere Produktivität und zwang uns, bei der Gestaltung und dem Testen unserer Komponenten bewusster vorzugehen. Außerdem wurde der Kunde stärker einbezogen, die visuellen Aspekte des Projekts wurden frühzeitig in den Vordergrund gerückt und die Art und Weise, wie unsere visuellen Spezifikationen gehandhabt werden, wurde unbeabsichtigt verbessert.
Es ist eine erstaunliche Software, die du dir ansehen und vielleicht sogar in deinen Entwicklungsprozess integrieren solltest.
