Building user interfaces is hard. Building nice interfaces is harder, and building exceptional ones is only achievable by the teams that have the best tooling. Today, we will talk about Storybook, one of the most essential tools in modern front-end development, and see how it helps us in building interfaces.
UI Development Lifecycle
Let’s do a small exercise and think about how to build the following interface: a to-do list page. It should allow users to view, create, modify and delete their to-dos.
First, set things up: create an empty component and add it to the routing. Then wire the component to the API to be able to manage the to-dos. At this point, we can run the dev server, go to the new page, and finally start building it.
Now, build the thing: implement various component states. Every time we want to build a different state, we need to update the backend so that it returns correct data to the UI. For example, after building an empty state for the list, we need to create some todos so that we get them from the API and can build a non-empty state.
🔍 Review Time
After all the components are ready and tested, we either deploy our changes to a preview environment or merge and deploy to dev/prod under a feature flag to show to our team.
Let’s say we got some feedback from the designers. They asked us to make some visual changes to both the empty and non-empty states of the todo list. Now, we delete all todos, tweak the empty state, create todos, and update the non-empty state. The design feedback is incorporated.
We deployed the new version of the page and… found that we caused a regression in one of the states. What do we do? You got it. We will update the backend to return the necessary data and fix the issue. And we’re done - everything works this time. We ship our change and roll out the feature to customers.
🤔 Was There Anything to Improve?
What we’ve done to build that page was reasonable - setup routing, manipulate the backend state to display what’s needed, review work with the team, incorporate the feedback.
But along the way, we had to constantly use the backend API to manipulate the data. Want to work with an empty state? Delete all items. Want to get a non-empty state? Create items. Want to get a state with particular items on the list? Same story.
We also introduced a regression in our simple dual-state page. Imagine what happens when you have not two but 10 states of your component. When you have to support every single edge case that can happen. Will you constantly update the data to switch to every state? How long will it take?
Thankfully, Storybook helps with exactly that! Let’s see how.
See it. Build it. Sorted.
Storybook is a frontend development environment. It allows us to build components in isolation, mock hard-to-reach edge cases, write visual & interaction tests, and much more.
🏖️ Building in Isolation & API Mocking
When building a component in storybook, we don’t have to add it to our application routing. In fact, we don’t have to run the app at all, bypassing the authorization and getting to the right page that renders the component. It saves seconds, but those seconds add up to a big waiting time.
Since there is no app running, we don’t need to rely on a backend API. Instead, we create a set of mocked responses, such as when there is no data, when there is data, when there is a network error, etc. Then, for each state of the page we want to support, we render a component as a separate storybook page (also known as “story”) and specify what response that particular story should get.
It allows us to develop various states simultaneously without making any changes to the underlying data - everything is mocked and defined in the story itself.
🦾 Automated Testing Feels Much Easier
If you tried to write tests for your UI components three years ago, it was probably quite a frustrating experience. Test runners like Vitest or Jest are great for business logic tests, but testing the visual components is a nightmare. Just compare these two screenshots of how the test error looks in Vitest and Storybook when an element you tried to query wasn't found.
The difference is clear - it’s much harder for a human to parse 100 lines of HTML and understand why the query failed compared to seeing how the component was rendered in the real browser and finding the root cause.
Additionally, with tools like storybook-addon-test-codegen, the time to write such tests goes down by an order of magnitude. Simply interact with your story, and the addon generates the test code for you. Copy-paste the generated code and the test is done! Now, if anyone breaks the component, they will know it immediately and won’t ship this broken component to customers.
storybook-addon-test-codegen makes writing tests 20x faster! I wrote more about it here: https://maecapozzi.com/newsletter/82
💅 Easy Peasy Design Reviews
Does this sound familiar: building something for a long time, only to be asked to change a bunch of things? You wish you had shown the result of your work to stakeholders earlier to get some early feedback and keep the number of changes small.
It’s easily achievable with Storybook. As you finish working on the stories, say, for one of the page components, put together a PR and deploy your storybook. Then, let your team see the piece that you build and comment solely on that. It will keep your PRs smaller (which is always a great thing), make incorporating the feedback faster, and reduce the mental complexity that you would otherwise have when shipping a big change.
🕵️ Visual Tests With Chromatic
Chromatic is a paid solution developed by the Storybook team. It screenshots your stories and compares them to their baselines (stories captured in the main branch). Whenever there is a change in any of the components, Chromatic highlights it and notifies the engineers.
A person responsible for making the PR checks the diff to see if the change is intended or if it’s a UI regression. If the change is expected, they can accept it. If it’s not expected, they can safely fix it before the PR lands. Visual testing catches a lot of UI issues that would otherwise go to production unnoticed.
Chromatic snapshots are different from HTML snapshots. An HTML snapshot generated by expect(element).toMatchSnapshot() is a raw HTML that is not parseable by a human eye. Whereas a Chromatic snapshot is a screenshot of the component that preserves all the styles and truly displays what your users will see.
Let’s summarize!
Storybook improves UI development by allowing us to build components in isolation, eliminating the need to manipulate backend data for different states. It makes testing intuitive with visual comparisons instead of cryptic errors, streamlines design reviews through easy sharing, and catches regressions with tools like Chromatic.
Storybook transforms UI development from a tedious process into an efficient workflow, helping teams create exceptional interfaces with less effort and frustration.
Useful Resources:
- Storybook & their Component Tests Overview
- Great guide on how to write component tests from Storybook team
- Storybook Test Codegen
