Key Takeaways From Storybook’s First Meetup in Paris
Automation + Tools for design system engineers.
Last Tuesday, November 7th, 2023, marked the first Paris Storybook meetup. I was fortunate enough to be part of this insightful event with like-minded professionals.
To be quite honest, when first arriving at the venue I was worried that I had shown up at the wrong place. But don’t let yourself be fooled by appearance. When I spotted the big neon sign behind the front desk with some strong language suggesting that reusing products is the way to go, I immediately knew I had the correct spot. We got there a bit early so not a lot of people had shown, but it started to get more and more crowded as the first session was about to start.
If you couldn’t make it to Paris, or the event livestream even, let me make it up to you by sharing some of the key takeaways from this enervating event.
Storybook (+ Chromatic)
The night was kicked off by one of Storybook’s core maintainers ‘Norbert de Langen’, taking us through the basics of Storybook and how you can leverage its strengths even further using Chromatic. Developing frontends and design systems can be quite challenging because the future is always uncertain. As Norbert rightfully said: “Abstraction is hard, but testing UI is REALLY hard.”
Storybook is all about developing UI components in isolation, removing the confusing contexts in which the component may be used. Most developers are familiar with unit-testing their code, and this is also certainly possible for testing your UI components. However, these tests often rely on virtual DOMs set by NodeJS and JSDOM. Storybook enables you to perform these unit tests in different browser contexts while also providing you with a visual representation of your component and any unexpected differences that were found compared to previous versions of your UI element.
The tests that you write for Storybook are run in ‘Play functions’ after the component has rendered. The developer also has access to a step-by-step trace of the test for optimal debugging, seeing the exact interaction that caused your new element to fail. There is also a test runner available for NodeJS, powered by Playwright, that can run Storybook’s play functions in parallel and cross-browser. If that wasn’t enough you aren’t even limited to running the tests on your local storybook project, but also against deployed Storybook projects.
By incorporating Chromatic into this equation you can set up automated workflows as part of your pull request cycles that allow for visual regression testing as well. A static build of your Storybook project is published to Chromatic and, like you are used to with GIT pull requests, a review is prepared for the stakeholders that you’ve set up for your specific use cases. Currently, a plugin is in Beta to run these visual tests right from within your Storybook dashboard.
Design System Compliance
Next up was Victor Michaud, Design System Manager at Doctolib, sharing with us how he and his team deal with the challenge of compliance with their design systems.
To tackle this, the team has built its own Figma-plugin to identify all compliant and non-compliant layers in the project. Using these numbers they can estimate a percentage of compliance using a proprietary formula. Doctolib has also developed an in-house extension for Google Chrome that highlights (non-)compliant elements in a live preview. These tools help them to identify any design system debt that they may be facing, such as missing components. The goal is not to reach 100% compliance as this would inhibit creativity. Striving for 75% or 80% design system compliance would be just as good, if not better.
Design Tokens
To close off the night we had Steve Dodier-Lazaro from our host BackMarket to share their experience with design tokens. Particularly how their team has struggled with changing design tokens throughout a complex codebase.
Design tokens describe general properties that are used throughout a design system. For example, color, spacing, and fonts can be captured in design tokens so that they may be re-used throughout your product. Contrary to popular belief Steve states that the use of design tokens does NOT make future brand changes easy as their team has experienced firsthand how much trouble it is. What it does however provide your team with is a formalized style declaration and uniform CSS.
When design tokens change, often the code has to be migrated, and most of the time this is done manually by the developers. This is where they have found a way to optimize this process. Migrating design tokens usually consists of a combination of value change, addition, removal, and replacement. To tackle these migrations the team has used codemodding to replace patterns in their code based on grammar. This even allowed for previously hardcoded values to be replaced with newly defined design tokens.
All in all, I look back on an interesting event with professionals who share a passion for front-end development. Many thanks to all the speakers, organizers, and everyone I have had a chance to speak to about our mutual passion.
