back

Component Driven Development

I recently talk about this topic a lot, but most of the time, people don’t know what I mean. So here is an introduction.

A lot of frontend code is developed top down. You start with the full design, build a basic structure, then start with a screen and develop the big components by creating smaller ones.

Development of an auth page: The AuthPage component is created first, its contents are created when neededDevelopment of an auth page: The AuthPage component is created first, its contents are created when needed

Component driven encourages you to do more bottom up. You start with the smallest parts, perfect them in isolation and only then, you combine them to bigger ones. Component driven enthusiasts believe that it leads to more durable and reusable code.

Development of an auth page: The small components are created first, the combined components are created afterwardsDevelopment of an auth page: The small components are created first, the combined components are created afterwards

Using this bottom-up approach makes it easy to create documentation and testing on a component level.

Most of the ideas that component driven development resonates with aren't new. For example, the idea of isolation is encouraged both in object-oriented programming (low cohesion) and functional programming (pure functions).

Benefits of Component Driven Development

Dealing with Change

In agile, requirements are not necessarily clear at the beginning. By making things work in isolation, it is easy to reuse components or change your interface structure later in development.

Animation that shows how components can be used in different places when they are isolatedAnimation that shows how components can be used in different places when they are isolated

Documentation and Coherence

Components and their variants are usually defined in the beginning. That makes it easier to reason about consistency: if management or design wants to introduce something that works different than usual, developers can refer to existing patterns and how they would work well in this scenario too.

A table showing different button variationsA table showing different button variations

Testing

Automated frontend testing is hard. There isn’t a lot of logic to unit test, so often, frontend developers write a lot of end-to-end tests. However, end-to-end are not only expensive, but they also tend to fail due to small, unrelated changes. Component Driven Development opens the doors to visual regression testing, which are the most useful tests in frontend in my experience.

Animation that shows how differences between an old and new component version are foundAnimation that shows how differences between an old and new component version are found

Responsibility

With isolated components, it’s very clear what part of the interface fails. The initial creator of a component can help you with problems. I like to think of them as component code owner.

Common concerns

Isn’t that a lot of work compared to just developing? My client doesn’t have time for this.

It is additional work in the beginning that will pay off over time. Treat your interactive code documentation as part of deliverables. By clicking through it, clients will have a better grasp of your progress, even if the components are not part of a page yet.

I use a component library. Is Component Driven Development beneficial to me?

Yes. Component libraries define your lowest layer of components (designers call them atoms). There are many more layers to implement to a full application. For example, you would combine component library inputs to auth dialogs, which then can be used in full pages.

Isn’t everybody already doing this?

To some extent. If you are a React/Vue/Svelte/… developer, you are very familiar with the concept of components already. However, most developers start with the big, combined components first or they don’t document and test on a component level.

How to get started

Establish a platform that you develop your isolated components in. This could be Storybook, but you can also use something different or create your own inside your project. Encourage other developers to use it.

Align with project management – tasks should represent components whenever possible.

Make sure your automated tests follow the component driven approach. It is hard to resist the effortlessness of visual regression tests when the underlying framework is implemented well.

I recommend the following resources: