The Benefits of Building in Storybook

Developers today are pretty much spoiled for choice when it comes to tools that help develop UI components. It’s almost as if the entire enterprise just collectively concluded that it is, in fact, the destination and not the journey that counts. At the end of the day, end-user experience trumps all, and if your priority is ensuring that their experience is exactly as you intend it to be, everything else falls in line behind that intention. 

This shift in focus comes from a new kind of testing called visual testing, which focuses solely on what is being displayed to the viewer. These tests allow developers to ensure ideal viewing conditions across all permutations of devices and software without having to worry about visual bugs slipping through functionality tests. Not unlike the way a police team performs a grid search in a swamp by combing through each and every inch of it, these tests basically hold each and every pixel on the user’s screen accountable to a screenshot. 

In addition to this shift in focus towards “end-result” (as opposed to the traditional “step-by-step” approach), another important trend in the enterprise is abstraction. Just as it’s easier to bake a cake in layers and then put it together, the enterprise has figured out that problems are easier to solve when they’re isolated. This is probably why Storybook is one of the most popular UI development tools right now.

Storybook is an environment that allows developers to build view-layer components in isolation.

While many people call it React Storybook, you can actually use it with Vue, Angular, or a number of other supported view-layer frameworks. One of the key benefits of Storybook is that it runs outside the main application, so developers can create UI components for different devices and operating systems without having to deal with or manage app-specific dependencies.

Storybook is based on a concept similar to that found in books you may have read as a child, where you could pick a different path and reach a different ending each time. Users all behave differently, and accounting for every possible action along with the accompanying on-screen implications is quite a heavy task. That’s why it’s important to maintain some sort of order in the form of a decision tree. 

Storybook does this by maintaining a library with all of the UI components in one place so that every possible state of each component can be tested and recorded separately. Each test result is then regarded as a Story, which is the smallest unit in a Storybook. Each Story can only contain one state of a given component, and it’s only when you put all of the different states of all of the different components together that you get the full Storybook. 

Visual testing, or visual regression testing as some call it, is a foolproof way to make sure that your UI is exactly what you intend it to be across devices, screen sizes, and operating systems. This isn’t done by Storybook itself, since it is more of a developers’ environment than a tool for visual testing; rather, the actual tests are conducted by an add-on called Storyshots. Storyshots is an integration between Storybook and Jest Snapshot Testing. 

Storyshots works by first taking all of the existing stories and converting them to snapshots (or screenshots) to keep on file. These screenshots refer back to the desired structure of the UI components, so every time any UI changes are made, new screenshots are taken to compare with the ones on file. If the tests fail for any reason, the developer has the option of either altering the original desired state or getting to the bottom of whatever is causing the irregularity.

The reason that visual testing is gaining such popularity is that all other tests have basically failed with regards to UI components. There are a few reasons for this (in addition to screen size complications), not least because it’s just really hard to measure UI components in terms of code. This is because every graphics card does the code-to-pixel conversion a little differently, and while it may look the same to a human, it’s night and day to a machine.

This brings us to one of the common problems with visual testing, which is the fact that even minor irregularities which don’t really affect the viewability of a page can cause visual regression tests to fail. This makes it necessary to always have a human involved so that judgment calls can be made as to how much deviation is acceptable. You can set fault tolerance parameters to allow for a certain degree of regression, but UI components aren’t exactly “parameter” friendly.

Storybook integrates well with a number of tools to automate visual testing. These tools use heuristics to both comprehend and ignore minor deviations in pixels that don’t affect the user experience.

In conclusion, as opposed to more traditional style guides where code has to be maintained in two places, Storybook lets you do it all in one place, which is why it’s often described with adjectives like “living” or “interactive.” This is because Storybook uses production code and live configuration to create, enable, configure, and test UIs in isolation. When you take into account the versatility that comes with the abstraction and integration that Storybook offers, it’s difficult to find a competitor that’s both as user-friendly and as developer-centric.

Twain is a Fixate IO Contributor and began his career at Google, where, among other things, he was involved in technical support for the AdWords team. His work involved reviewing stack traces, and resolving issues affecting both customers and the Support team, and handling escalations. Later, he built branded social media applications, and automation scripts to help startups better manage their marketing operations. Today, as a technology journalist he helps IT magazines, and startups change the way teams build and ship applications.