StatusCake

The endless capabilities of Storybook

storybook

As a developer, I am a massive fan of documentation and (as you can probably tell from my previous blog post) also a big fan of Storybook. If you’re interested in what Storybook is and how to set it up, or integrate it into your existing project, you can find out more about that here.  However, in this post, I am going to be outlining why you should be using Storybook and each of its features and capabilities. This is in addition to (at the time of writing) some exciting new additions to the library.

Why should I be using Storybook in my project? 

There is a reason so many big name brands such as GitHub, Mozilla and Airbnb use Storybook to document their components. The first (and in my opinion the most redeeming) benefit of using the library is that it is the most extensive and detailed way of documenting your components. Within Storybook, components are thought of as ‘alive’. What I mean by this, is that the component within Storybook isn’t just a static snapshot of that component at a certain time, it is the component itself at any given time. So whenever changes are made to that component within the codebase, the story will reflect those changes too.

You can also add the integration of ‘controls’ to make your component completely interactive as if it were on the live site. The best part of this is that these controls have a very user-friendly interface, so each user (no matter their technical capabilities) is able to see and interact with the component in every state that it has. I have found that this is a very useful tool to increase collaboration between both development and design & UX teams, as it acts as a single source of truth for all of the components within your codebase. 

Docs, docs, docs 📝

The next benefit (from a developers perspective) is the great way that it documents the technicalities of the component. We’ve all been there, when you’ve worked on a large codebase for a while and you come across a component that you haven’t seen for too long and you’re not sure what the hell it even does. Similarly, you could be a developer that is new to a pre-existing codebase and need to familiarise yourself with the components available to you and how they work. This is where the ‘docs’ Storybook addon comes into play. With story docs, you can add a description of the element as well as being able to view it in a sandbox. The best part of this though, is that each of the props that are passed through to this component are laid out in a grid with descriptions, so you can easily view the data and variables that go into a component and how they affect that component if amended.

Speaking about docs, in addition to being able to add documentation for each component on a per-story basis, with Storybook you can also add what are known as ‘doc blocks’. Doc blocks are separate pages that sit outside of the component folders. They are used to add much more generalised information about the project, such as an introduction page, or a theming page such as typography. It is completely up to you how extensive and in-depth you want these doc blocks to be, but in my opinion, every little (bit of documentation) helps.

Storybook testing 🧪

Now, moving away from documentation for a little bit, another significant benefit of integrating each of your components into Storybook is the testing capabilities that it gives you. With your components now in isolation, visual tests can be created to ensure no visual regression when you are writing your day to day code. This, to me, is a very powerful addition to any codebase and can work very well alongside any functional or end to end tests you may already have.

This leads nicely on to a very exciting feature that (at the time of writing this blog post) is currently in beta mode. Storybook Interaction Testing will elevate the current testing capabilities within Storybook and allow you to write UI tests within stories and (using the new test runner) execute them. This is a great addition to the visual tests as you will be able to verify both looks and logic at the same time.

A new way Of working 🛠

A great feature of Storybook that I personally benefit from when working day to day is the fact that each component is visible and can be worked on from the sandbox that it lives in within its story. This means that when you are creating a brand new component, instead of needing to add it to a page to work on its UI and styles, all you need to do is make a story for it. This is also fantastic for code review as well, as instead of having to search through a website to try and find the component you are reviewing, you will always be able to find it on your Storybook instance as long as a story has been created for it.

Additional addons ➕

There are also a multitude of addons that you can add to your Storybook integration in order to elevate its capabilities even further. I will list some of my favourites, but there are many more that you can explore here

The first (and my personal favourite) is an addition that both makes your components more accessible, as well as maintaining any accessibility standards you may already have. storybook-addon-a11y is really simple to install and adds another tab onto your story to allow you to run Axe to let you know where you are going wrong in terms of the components accessibility. As well as running it on your existing components, you can also use it while you are coding and creating new components, to ensure high accessibility standards are being met at all times. 

storybook-addon-designs is another fantastic addon that improves collaboration between development and design teams. Using this addon gives you an extra panel on your story, where you can view the design of that particular element directly from Figma via a link. Alternatively, if you use other design tools on your project (e.g. Adobe XD) there are other addons that work with those too.

Another valuable addon for Storybook would be storybook-links-addon. This allows you to navigate between your stories by using links, instead of having to use the sidebar. This makes the user experience much nicer.

Final thoughts on Storybook

In conclusion, Storybook itself is a super powerful addition to any project and you can use each of its capabilities to improve code quality & accessibility, increase collaboration between teams and ensure no regression of your existing components using the testing integrations. As mentioned before, if you are now interested in introducing Storybook into your project, as well as using the fantastic docs, you can also view my tutorial blog post to show you how to do that.

Share this

More from StatusCake

When Code Becomes Cheap: The New Reliability Constraint in Software Engineering

4 min read How AI Is Shifting Software Engineering’s Primary Constraint For most of the history of software engineering, the primary constraint was production. Code was expensive, skilled engineers were scarce, and shipping features required concentrated human effort. Velocity was limited by how fast people could reason, implement, test, and deploy. That constraint shaped everything from team size,

Buy vs Build in the Age of AI (Part 3)

5 min read Autonomous Code, Trust Boundaries, and Why Governance Now Matters More Than Ever In Part 1, we looked at how AI has reduced the cost of building monitoring tools. Then in Part 2, we explored the operational and economic burden of owning them. Now we need to talk about something deeper. Because the real shift isn’t

Buy vs Build in the Age of AI (Part 2)

6 min read The Real Cost of Owning Monitoring Isn’t Code — It’s Everything Else In Part 1, we explored how AI has dramatically reduced the cost of building monitoring tooling. That much is clear. You can scaffold uptime checks quickly, generate alert logic in minutes, and set-up dashboards faster than most teams used to schedule the kickoff

Buy vs Build in the Age of AI (Part 1)

5 min read AI Has Made Building Monitoring Easy. It Hasn’t Made Owning It Any Easier. A few months ago, I spoke to an engineering manager who proudly told me they had rebuilt their monitoring stack over a long weekend. They’d used AI to scaffold synthetic checks. They’d generated alert logic with dynamic thresholds. They’d then wired everything

Alerting Is a Socio-Technical System

3 min read In the previous posts, we’ve looked at how alert noise emerges from design decisions, why notification lists fail to create accountability, and why alerts only work when they’re designed around a clear outcome. Taken together, these ideas point to a broader conclusion. That alerting is not just a technical system, it’s a socio-technical one. Alerting

Designing Alerts for Action

3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams

Want to know how much website downtime costs, and the impact it can have on your business?

Find out everything you need to know in our new uptime monitoring whitepaper 2021

*By providing your email address, you agree to our privacy policy and to receive marketing communications from StatusCake.