Adding StoryBook to our workflow
A failure story
For the past two months, Pepe and I were working on a redesign project for a new client, the goal of the project is to pay some of the technical debt this customer has. They’ve been running a business for several years on top of a PHP app with tons of legacy code that was getting pretty unmaintainable.
We decided to split this app into two separated ones, one for the frontend and the other for the backend. This way the former contractor the client had could focus on providing an API while Pepe and I work on the frontend.
The plan seemed like a good one, but things didn’t go as expected, the other provider was having a hard time delivering the API endpoints we needed, and this problem was delaying us and our ability to show progress. We couldn’t just show a bunch of disconnected components, or could we?
That’s when I realized we could use StoryBook to show the client our progress without building much harness code that was likely to change shortly.
The StoryBook
Storybook is a tool that integrates with your current react app and allows you to develop components in isolation. That means, instead of developing your component inside a parent component it provides a blank sheet where you can build without worrying about anything else.
You may think this is not needed, or that you have enough practice to do it correctly without any complementary tools but at least in our case, it helped a lot. Bear with me; it has some significant advantages.
Component variations
Every time I write a component I overlook the variations it may have. Because my goal is to finish the page I’m working on, my primary focus is in the best case scenario that gets my page to render correctly.
Since StoryBook is disconnected from the page and its main feature is to present the different variations of a component it forces me to think about that first.
Imagine a simple table:
<Employees list={this.props.employees} sortable />My first instinct when creating this type of component is to get a table rendering.
But if you want to have this rendering on a StoryBook the tool will ask you to think about the variations, here is how Employees may look like in a StoryBook definition.
import React from 'react';
import { storiesOf } from '@kadira/storybook';
import Employees from '../components/Employees';
storiesOf('Employees', module)
.add('with empty list', () => <Employees list={[]} />)
.add('with one element', () => <Employees list={[employee1]} />);
.add('with one element and sortable', () => <Employees list={[employee1]} sortable />);Similar to what happens when unit testing things upfront, storybook forces you to think about the input(s) (and their relations) beforehand. In this example, should I make the list sortable if it has only one element?
Avoid API leaking
Another great feature storybook provides for my mental model is to un-tight the structure of the objects that live in the store (either redux, mobx or local state) from the props.
Should I have an employee list or maybe just a generic table with some config options will do?
This type of questions helps me draw the line between how much coupling I want my components to have with the data structure saved in the store.
Collaborate in the open
As we develop the app, the client wants to check the progress, and we want them to check it, so we can correctly set the expectations.
Having this tool helped a lot to close the feedback loop, we experiment with new UI solutions in the open by deploying the storybook to an internal URL and gather enormous feedback that gets us closer to what the customer needs.
Wrapping up
So far we are pretty happy with development process storybook has enabled us and I have a lot more to share in a follow-up post like how to use it with connected components or how to set up testing directly inside storybook, but that's for another post.
As a conclusion I encourage you to check storybook, it’s very unobtrusive and easy to set up. If you are lucky enough to use create react app, it's even easier; the CLI does everything for you.
Do you like React and want to help us building amazing products? Drop us a line.
About ingenious
Ingenious is a distributed company with offices in Montevideo, Uruguay, and Denver, Colorado, and people in more than five countries. We build software for challenging industry segments like healthcare and government where most of the software sucks.
