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

Engineering

Beyond Uptime: Building a Self-Healing OpenClaw Observability Stack

3 min read The allure of OpenClaw is undeniable. You deploy a highly autonomous, self-hosted AI agent, give it access to your repositories and inboxes, and watch it reason through complex workflows while you sleep. It is the dream of the ultimate 10x developer tool realized. But as any veteran DevOps engineer will tell you: running an LLM-backed

When AWS us-east-1 Fails, Much of the Internet Fails With It

7 min read There are cloud outages, and then there are us-east-1 outages. That distinction matters because failures in AWS’s Northern Virginia region rarely feel like ordinary regional incidents. They tend instead to expose something larger and more uncomfortable: too much of the modern internet still behaves as though one place is an acceptable concentration point for infrastructure,

In the Age of AI, Operational Memory Matters Most During Incidents

7 min read Artificial intelligence is making software easier to produce. That much is already obvious. Code that once took hours to scaffold can now be drafted in minutes. Boilerplate, integration logic, tests, refactors and small internal tools can be generated with startling speed. In some cases, even substantial pieces of implementation can be assembled quickly enough to

AI Didn’t Kill the SDLC. It Made It Harder to See

10 min read Whilst AI has compressed the visible stages of software delivery; requirements, validation, review and release discipline have not disappeared. They have been pushed into automation, runtime and governance. The real risk is not that the lifecycle is dead, but that organisations start acting as if accountability died with it. There is a now-familiar story about

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

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.