Storybook is great. Seriously great. As a design-minded, front-end React and React Native developer, creating clean, functional, pleasing-to-the-eye user interfaces is my primary concern. And – as you likely already know, because you are considering using Storybook – this type of UI development is often frustrating for sundry reasons extending beyond responsive design and cross-platform browser testing. Perhaps you have been tasked with creating a UI without any data to pull from yet. Maybe there’s no navigation or screens in place to render components from, but your client still wants a glimpse of the site’s UI. There are so many situations similar to these where using Storybook saves the day and speeds up development, and not just for web applications, Storybook works within React Native for visual testing of mobile apps as well!

Let's talk about what Storybook is and does: Storybook is an open-source tool that allows the rendering of UI components in isolation. You can see and test every React component you make, no matter what. That almost seems like enough of a selling point, but just in case, here are what I consider to be five of the most magical benefits of using Storybook within React development. If you’re still with me by the end of the article and looking to learn Storybook basics, we can take a walk through setting up Storybook in a React application and building a component.

1) Storybook Provides easy Access to hard-to-reach components

Is this a familiar story? You’re working on an app where components behave differently based on user permissions? Or maybe you are working on an onboarding process that requires collecting and validating documents before a user can progress and access certain feature screens? If you said yes to either of these, you have my sympathies. Testing your components in those situations can be a nightmare. At the risk of sounding like a broken record, I'll say that Storybook renders components in isolation, so you can see every component without even running your app. Infinite variations of your component can be rendered in the Storybook interface, populated with ‘args’ (basically just dummy data being passed as props to your story) that YOU have assigned, simulating everything from common states to thee-hardest-to-access state cases.

2) It serves as a visual component library

One more hypothetical scenario: you’re building a large-scale app and bringing on new developers as the project grows. When new folks dig into the code, redundant components start showing up in the pull requests because the repo is dense and it’s tough for folks new to the project to locate components built and tucked away. However, if you’ve been building all your components in Storybook this is less of an issue. New devs can run the Storybook interface to get a glimpse of all available components, then pick and choose what’s needed for a new feature. It’s a super-easy way to document components and create less redundant code.

3) It aids in Component Driven Design

CDD and Atomic design are paramount in today’s tech world. Storybook can be your microscope. Start by creating the smallest components; make sure they pass unit tests; render them in Storybook to fine-tune their design and test responsiveness. Assemble bigger, more complex components using your tested smaller ones. You can keep building until an entire feature screen is rendered and tested in Storybook. Speaking of testing, while you can visually test components with Storybook, you can also use this Storybook plugin to mock an API endpoint and test how data is received.

4) It allows you to change the design on the fly

This is great in the early design stages, if you have a client involved in the design process, or if you’re just gathering feedback. With the storybook interface, you can easily and quickly change color, size, verbiage, etc without even touching your code. It's great for last-minute tweaks or projects without wireframing/mock-ups. Use your code to put images on the screen and see what works.

5) It helps build responsive React components

Ah yes, the wrinkle that ruined a million boot-camp react applications: mobile and tablet view. Storybook comes stock with several mobile and tablet view options, but you can seemingly add any mobile device to the list and see how your components react. Watch them break and then add your media queries/ ‘use window size’ hook to save the day.

Okay, now that I’ve described the benefits of using Storybook, let's see how Storybook works by building and rendering a component. I'm using Typescript in this example, so if you use my code as a guide be sure to run npx create-react-app my-app --template typescript (If you are new to TypeScript I cover some basics in another blog post). Once React is good to go you can run ‘npx storybook init’ (or even ‘npx sb init’ if you are pressed for time) to install Storybook.

You’ll notice that Storybook comes with several example stories that help to get an idea of how it’s working. Take a moment to look through and render each component so you can get a feel for what’s going on. I’ve noticed that opinions differ here, but I prefer to build my components where they will actually live in my repo, as opposed to in the storybook file that is created when Storybook is installed. This speeds up development even more because my components already live in the main portion of my repo and are ready to be hooked up to the backend. You'll notice that Components are built just like normal; There is no extra, Storybook-specific code inside of them. All of the magic happens inside files ending with stories.tsx nested within your Storybook directory.

For this little example, I decided to build a card component for my cat website that includes an image, a title, a small snippet of article text, and an anchor link to read more. I'll be building this all quickly so it’s not exactly as bottom-up/CDD as it could be, but I'm still hoping to illustrate how Storybook makes everything quicker, easier, and more organized. In my Card component, I'm importing an Image component as well as a styled anchor link component, but I just have my text header and snippet props surrounded by p tags. I’ve also built a CardList component that maps through my data and renders through my Card component. All of this should seem pretty ordinary, but let's take a look at how I’m rendering it with my CardList.stories component.

In this file, we will be exporting a function that returns our component with some provided props (referred to as Args in this case). Here is what's going on in greater detail: On line 1 I’m importing ‘Component Story and ComponetMeta which allow me to set types so that TS doesn't get ticked at me. On line 3 I’m importing the component(s) I want to render (in this instance, the CardList). Lines 5-8 are how I set my default exports. Line 6 allows me to organize stories within directories in the Storybook interface with ‘export default title’. You’ll notice in the screenshots of the storybook interface that the sidebar’s main directory is ‘Sandbox’ and that ‘CardList’ resides inside of it. On line 7 I specify which component I’m rendering and on line 8 appease TS. Line 10 and below is where I will export functions returning variations of my component. Notice on line 10 that I created a template of this function so it can be used repeatedly without writing the function more than once. Depending on how you go about populating your components you might not need to mess with a Template, but it is often helpful in reducing wet code. You’ll notice on line 13 I wrote ‘export const Primary’ and set it equal to ‘Template.bind({}).’ This is where I create my story using my Template function defined on line 10. Finally, take a look at lines 15-35. This is where I provide the args that populate my story.

Now ill run ‘yarn storybook’ to load the Storybook interface and see what I’ve got. At first glance, the component by itself looks pretty good!

But when I switch to look at my list story I realize I didn't put a height/width cap or any sort of object-fit on my image component. It doesn't look great…

This would likely have been caught earlier if I had spent more time rendering my components at an atomic level, but never-the-less I’ve caught it and corrected it now.

Not too bad! But let’s check how responsive it is.

I was expecting the worst and I think I got pretty much the worst. But a few media queries later and we have:

Now that’s looking better! I probably still need to do some work to make sure the text doesn't pop out if the screen is somewhere between full width and my tablet breakpoint, as well as test how it reacts to different data being fed to it as args, but I think this should illustrate the ease at which you can create UI components that are responsive and react as intended in multiple use cases. I now have an example of this card component living in my repo just waiting to be utilized as I build the project, and it took me very little time. Love it. Seriously.