Storybook is a tool my team has been utilizing in React to effectively develop reusable components. Simply put, Storybook is a kitchen sink of components written by a dev team that can be implemented in an application. It provides a standalone development environment based on stories defined by the user. I will be speaking to our usage of Storybook with React, but it also supports Vue and Angular 4+.
We have found that Storybook provides a myriad of benefits:
- Faster development time of reusable components
- Faster development time of complex components
- Better edge case coverage
- Quicker feedback loops between designers and developers
- Provides technical documentation in an easily consumed format
Faster Development Time of Reusable Components
We’ve all developed bite-sized components intended to be reused throughout an application. Custom select elements, input elements, buttons, cards, headings, you name it.
However, when do you typically develop these? In my past experience, it has been in an isolated use case. First feature is login? Don’t have inputs yet? Guess you’ll have to develop them to get your feature done.
What this does is bloats the development time of the first features and creates a scenario where a second developer working on another form is now dependent on the login feature.
Storybook allows for an input field story to be broken out into its own because not only can it be developed in isolation of any other feature, it can also be verified outside of any feature, as well. There’s significantly more focused QA done on these stories, as it is a very specific set of use cases.
The first sprint of our application development was devoted to building these reusable components in order to allow us to piece together more complicated features with ease in future sprints. This was our first huge win from Storybook.
Faster Development Time of Complex Components
My personal favorite thing to brag about when it comes to Storybook and how we structured our project is the speed of development of our most complicated components.
Utilizing Storybook, we are able to piece together the building blocks of the application into a more complex component without having to be in the main application. This is a powerful feature for us to utilize because we are able to develop these components without having to navigate through the app or have to authenticate in the app for each and every change we make.
In addition, we are now able to split each of our complex features into two testable features. One being that of the display of the component which can be verified in Storybook. The other being that of connecting it to the API and our Redux store, verifiable in the application.
This allows us to go to peer review and QA much faster since we aren’t dependent on hooking up the API (via Redux actions/reducers/selectors).
Better Edge Case Coverage
After realizing the benefits of Storybook’s “Story” feature, in which you can add multiple use cases to a single Story, we realized that this can be utilized for complicated edge cases. Our APIs are rather complex and have several nuances that are difficult to set up in the application in order to verify functionality.
However, if we can simply pass attributes to a React component representing these edge cases, we can quickly develop against the predefined data set. In addition, we will always get a consistent result. This is hugely beneficial considering our environments cycle often.
This was achieved by having the concept of a ‘presentational’ and a ‘contextual’ implementation of every Redux-aware component we develop. Our contextual components are simply wrappers around our presentational component and hooks all of the Redux properties to the component using the
connect higher order component.
Implementation of the presentational component in Storybook allows us to not have to worry about setting up a store so that our selectors properly function. This allows us to also refactor the store shape with relatively little side-effect to the bulk of our application, as well.
Not only does base Storybook allow multiple stories highlighting behaviors of components based on inputs, but there are add-ons that give users even more flexibility, such as knobs. Let’s say we have a chart that changes color based on the values passed in. We can tie data from the knobs add-on directly into the props of the React component, and can manipulate them live. This is great for concise stories, but dynamic behaviors.
Quicker Feedback from Designers
The last two apps I’ve developed have included “UX-QA” sessions where designers will tell developers what area of the application to navigate to and look for inconsistencies and issues that may have been overlooked. Since our application is highly dependent on the API to view certain features, we are missing large swaths of the application.
Storybook gives us the ability to not only show potentially all features of the application, but also is extremely simple to set up on somebody’s computer. This means we can cut out a ton of wasted time since designers can simply focus on features inside of Storybook. They are able to come to the table with a list of defects to knock out one after another. With this list & the ability to make the changes with live feedback, these QA sessions are much more effective in terms of developer time.
Pro Tip: If you need to sell Storybook to non-technical people, make sure to talk about time savings considering how expensive technical expertise is!
Tech. Documentation in an Easily Consumed Format
One of the really cool features about React’s implementation of Storybook is its ability to interpret PropType definitions from the component being displayed in the story.
The definitions are displayed in a table format displaying what properties can be passed, what the prop type is (including displaying object notation of
shape prop types and unions when doing
oneOfType ), default props, if it’s required, as well as a description.
It’s really impressive, to me. It interprets the properties very easily and the description is simply a comment in the code above the property. We utilize this feature to communicate exactly what is expected by the component to render properly.
If this article has piqued your interest in Storybook, please leave a comment or “clap” the article and I’ll do a follow up about implementation details of Storybook such as how we utilize add-ons, decorators, and all the other features I mentioned here!