In the land of web development, there are countless ways to build user interfaces. With lots of frameworks and libraries containing every feature possible. But they all have one thing in common - they build on components. The best-known frameworks are React, Angular and Vue. These are used in the majority of projects, even at Ergosign.
A user interface must work without error while being visually appealing and intuitive to use. A challenge that design and development must solve together. The design must be developed consistently throughout the application.
In web development, this is best achieved by using UI components. So that each component is used “cleanly”, the focus is primarily on the properties of encapsulation regarding individual functions and simplified testing. Alongside functional unit tests, manual design reviews, mobile responsiveness tests and accessibility (a11y) tests are also required. In Storybook, we have found an open source tool that lets us build UI components more quickly and efficiently than ever before - thanks to our very own add-on.
Storybook: fairytale UI components
No, we’re not telling tall tales. If you’ve never heard of Storybook, you can read the following description on the website:
„Storybook is an open source tool for building UI components and pages in isolation. It streamlines UI development, testing, and documentation.“
We have to agree. Storybook offers plenty of benefits for us, such as:
Isolated development of components regardless of later application.
Documentation of use cases in simple JavaScript. This makes for easier development, testing and checking in quality assurance.
An overview of all components in a live gallery with related documentation.
Simple (manual) visual testing of components in various browsers.
And the cherry on top: Storybook supports all modern frameworks.
A wish come true for easier, more efficient development and better quality assurance with Storybook. Why are we so enamored, and how did we come up with the idea for our Storybook add-on? To answer that, we have to look to the past. How did we build UI components before?
Once upon a time, there was… UX Library
Before using Storybook, we worked with a similar tool that we had developed ourselves. UX Library offered an overview of all project components in an isolated environment.
Here, all components can be seen in their various versions and pseudo-states (such as hover, active, focus). So Design and Development can see all the necessary information at a glance. But UX Library has some limitations compared to Storybook.
Not all frameworks used at Ergosign were supported. Maintaining the library and regularly updating the relevant frameworks was very time-consuming. Edge cases, so stories with complex examples, were difficult to create. When styling pseudo-states, these had to be manually added to prevent artefacts in the build-output.
A quest to technical lands
Storybook offers good solutions for the problems encountered when using UX Library. But there is no opportunity to display the various pseudo-states and characteristics at the same time.
You have to click a button to see these in their active state. The only way to force the element into styling the pseudo-state is to define and apply it normally.
This requires two steps:
Step 1: Define a normal CSS class that describes the same appearance as the pseudo-state.
Step 2: Apply the class to the element, i.e. it must be added to the relevant class attribute.
Step 1 in more detail: Automatic generation of pseudo-styling
Thankfully, a plug-in for PostCSS („A tool for transforming CSS with JavaScript“) has already been developed that allows the automatic generation of CSS classes from the pseudo-state styling in CSS files. It can also be found as an open sourceproject on Github and furnished with additional functions by using pull requests. We also offer additional presets that automatically adjust the configuration with Storybook and Webpack. These integrate and configure the plugin in the PostCSS loader. The other classes are only created in Storybook and the final build output in live systems is spared from unwanted artefacts.
Step 2 in more detail: Applying pseudo-styling
In the next step, the various states have to be displayed. In the story, you define which pseudo-states should be shown. In addition, further attributes and/or framework-specific properties can be filled with values that are also applied to the relevant components (code example of story definition).
The component is rendered multiple times in Storybook Canvas and the relevant generated pseudo-state class is used.
The idea for an add-on is born
Our Storybook add-on closes this gap. Both steps are automated by the add-on. All pseudo-state styling for the component is automatically translated into real CSS classes, and the story definition lets you easily define which states are even presented. A real improvement!
An insight to the add-on: