Our experience using Storybook for React app

Recently, our team started using React Storybook. In this post, I’ll share why we made this decision, how we did it, what challenges we met, and the conclusions we’ve drawn.

What is React Storybook?

React Storybook is a UI development tool that allows you to run, view, and play with your React components isolated from your React app without the need to run a complex dev stack. React storybook runs its own web server and provides a nice catalog view of your components. It’s a design system and can be used as a design source of truth for your React projects.

Every React component receives props. React storybook allows you to pass and change props to your component through UI and play with it. Using a storybook, you can test all component states just by changing your props. Also, as a developer, you can manually define a component state section for each component to improve the navigation between different component states (Percentage, Integer, IntegerRange, Currency for Numeric component).

Why did we decide to use React Storybook?

Our team is responsible for overseeing a big CMS project that is used and modified across the company. To make it work, you have to give other teams a chain of tools to let them develop their features fast, with minimum friction, using a unified design voice.

A really important tool needed in this equation is design — you want your project to look, feel and behave as consistently as possible, but at the same time, you don’t want to waste time thinking about styles and components.

In order to address this need, you have to build some source of truth to your design components and make it available for everybody who wants to modify or build one of the project features.

One of the biggest advantages of using Storybook is that product managers can easily view and plan what they will receive from their teams without really thinking about component design, features, and business logic. they can simply play with relevant components and share the relevant state of a component with their teams.

For us, it’s a way to share our design decisions through the code and give everybody an easy way to use this design.

import { HappyCoderZone } from 'xsite-react-components';

How did we start using the React Storybook?

• Availability: one of the first things we did is to make it available for everybody in the company, we built a CI/CD pipeline for faster development of storybook components, and deployed our storybook to the company web, just to let us and other teams build new features using storybook fast fast fast ….
• Build a Base Components: build your project’s basic components like Button and DropDown, etc… with all needed variants and examples and move your project to use them from the storybook just to make a components design and functionality standard for other team members, product managers, and teams.
• We made it easy to build a new component: we integrated Hygen to create our components and stories with just one command. Just to reduce the new component’s development time.

npm run component:create HappyCoderZone

• We moved our Reusable components to the storybook: Every system has multiple reusable components like Popup, FileDropZone, and HeaderButtons. We moved our reusable components to the storybook, just to let everybody play with it to make better plannings and estimations.

• Tests: When we moved our Reusable components to the Storybook we also moved their tests to the Storybook, we want everybody to feel comfortable by using our Design, just if you are using our React storybook components, be sure that it’s well tested and verified.

Challenges

• Usability: Due to historical reasons, we used the Material UI and Semantic UI React together in one project, one of the problems with this approach is that the callbacks and styles are really different between the libraries and don’t really live together. You don’t want to make any big refactors in your project to use the Storybook, because of this you should build your components to be generic for both callbacks and styles.
• Tests: When you are running tests using Enzyme, you always simulate some components events to test your logic, the events contracts can break when you switch your component to another library like Material UI React, to avoid this we always tried to be backward compatible for all callback types.

Conclusions

After we started using the React Storybook, we started to make better, more organized designs. Product managers received a transparent and clear design source of truth, and now as a feature developer using Storybook, you don’t really need to think about design; just add your component from the storybook and voilà — write your logic.