#vuecember2020 #frontend

Storybook

We use Storybook in every project to showcase our components separately and make them testable. Why we do this? Here are some advantages of using it:

Encapsulated components

We initially develop components only in Storybook, instead of integrating them directly into the interface. This lets us develop them in an ideally encapsulated environment - because Storybook is the first place of use for the components we build. The actual use in the interface follows later on.

This encapsulation forces every developer to design a useful data interface for the respective component. It also makes it very easy to avoid mixing data logic and presentation logic. This decoupling facilitates refactoring later on, because only the data or the representation layer has to be touched.

Furthermore, we can ensure within Storybook that the desired responsive behaviour is implemented correctly.

Easier QA

By providing Storybook during deployment in addition to the actual interface, the handover of components is much easier than without it. We are able to send a specific link to our UX/UI designers and all other parties involved. They can view the components separately and put them in all possible states that are necessary. Without Storybook, it is often difficult to create a specific component state in the actual interface.

image2020-12-8_14-42-0.png

This work has been made even easier by the still quite new Controls Addon. The conversion of stories from the previous Knobs addon has already been carried out in various projects and has noticeably streamlined the story creation process.

Visual Regression Tests

In some projects we also use Storybook stories to perform visual regression tests with the storyshots addon. By encapsulating the components, screenshots of the components can be created rather easily in different viewports. We then compare them to some base screenshots within our CI. This way we ensure that components are not accidentally changed visually.