Component driven development with storybook

Faster and simpler development are some of the pros of using Component driven development. Still, to build composable systems easily and correctly, some practices and guidelines are essential to follow. This article brings useful insight into what is important to consider when using Component driven development through showcasing a Storybook for React example.

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.