Component Driven Development with Storybook

We currently have many options in terms of technologies and approaches for building rich and expressive frontend applications. With frameworks like React or Vue, the emphasis is placed on components and smaller chunks, focusing on composability. However, components themselves don’t necessarily have a logical boundary or a guide on how they should be built. Therefore, some thought can be put into how we can tackle building such composable systems. 

Workflow options

Many product development teams are interdisciplinary, formed by members with specialties in different areas such as designers, product managers, testers, backend developers, and frontend developers. In a common workflow, the design is made first, which is then succeeded by backend development in which API endpoints and data are created. Frontend developers usually start building the app after some API endpoints are available because it's more convenient to build the screens with real API calls than it is with data mocks. However, building the frontend application this way can result in a challenging architecture of UI components if we’re not careful. Approaching the development of an application as a series of screens might lead us into coupling logic too much to a certain screen state, lowering the general reusability of our modules.

Moreover, in a lot of teams, common design elements such as inputs, tables, forms, and typography are created very early in the process. Hence, the question we can ask ourselves is whether there exists a way to push the frontend development a bit earlier in the process, without sacrificing quality and code relevance?

By optimizing the workflow we build the frontend with, we can improve collaboration between all team members, and most importantly, create a bridge between design and development.

A parallel approach

In order to achieve development velocity and less coupling to screens, the frontend should rely less on backend services and architect its modules more towards presentation and data. This means that frontend development should be able to start as soon as some screens or design components are ready. While backend development is creating data and business structures of the app, the frontend part of the development can be focused on building small components that will serve as a blueprint for the implementation of features and screens. As we don’t need to focus on building whole screens first, we can introduce a separate development environment, specifically engineered for such technique — Storybook. 

Component by component

Storybook provides an environment for decoupling the presentation from application and business logic. It is an open-source tool for developing UI components in isolation for React and similar frameworks.

It’s best to think of Storybook as a blackbox that simulates the boundaries and behavior of a fully connected web application. At the same time, it enables the developer to focus on the app's smallest parts, without having to dig through screens, forms, and edge cases only to see a component in a certain state.  

Let’s see a practical example.

Component featuring multiple input fields, checkboxes, submit button, and text.

Imagine we are given a design of a form for downloading a PDF report that consists of a few distinct visual elements — text inputs, checkboxes, links, buttons, titles. Alongside that, it should have a functionality that triggers a download after the user consents to the subscription and clicks the download button. We could approach the development of that form in many different ways. Of course, having the full context of the design in terms of other pages and a style guide is also important and it could influence our decision on choosing the development approach. But, roughly, there are at least two approaches to this problem:

• Develop the component with layout and business logic connected

• Develop the component as a small two-part system, consisting of presentational and business layers

The latter may seem like an overkill approach for a relatively small component. However, there are certain pros to this approach that are best manifested through setting up different states and edge cases for this form. If we want to see our component in different states, without manually filling the form, we need to have the ability to always pass a fixed set of parameters to it for a given scenario. This is where Storybook for React comes in handy. Storybook enables us to create mocked views that express a component’s state and behavior with a given set of data and parameters. By developing our component primarily for the presentational part, and creating a Storybook for its states, we can see how the component will behave and look in certain scenarios.

Download report - subscribe checkbox error

Download report - success

After we configure our arbitrary scenarios, we can develop the component further in those states, as Storybook allows us to recompile our code and refresh the app during runtime.

Team benefits

This approach is especially helpful in the long run for other team members. Onboarding new developers into the codebase is now a bit easier process. If the Storybook is well thought out, they can see a living style guide and a practical system that shows what parts of the application are already developed and how they can be reused. As the whole Storybook system can be deployed to its own website, it can also be helpful for designers as they can verify how their vision is transferred to engineering, further encouraging collaboration and discussions.

How to start with Component Driven Development

Storybook has an interactive tutorial that I encourage you to try out, play around with, and research on whether it fits your process and product. You can find many more useful examples of Storybook for React online.

After you’ve mastered the basics, there are a lot of helpful addons that can be used to further expand the Storybook system such as controls and documentation.

When you’re convinced, expanding your development environment with Storybook should not be too complicated of a process as the Storybook tries to configure your environment for working out of the box upon installation. If you encounter challenges, adapting its webpack config to fit your tech is generally something that fixes most of the issues.

Summary

In its gist, component-driven development is a workflow for creating frontend web applications by developing small & reusable building blocks. I hope this article brought you some clarity to this abstract concept. Storybook is a very helpful tool for trying this approach, but there are other systems out there that can deliver a similar result. The most important part is having the long-term discoverability and decoupling of presentation and business logic.

Happy building!