Component-Driven Development (CDD) is a development methodology that anchors the build process around components.

It is a process that builds UIs from the “bottom up” by starting at the level of components and ending at the level of pages or screens.

explain

Benefits

So what is the big deal about working one component at a time in a fixed series of states? Let me count the ways:

  1. Focus development: Working on a single component by manipulating an entire app into a certain state is painful and laborious. Certain states can be difficult or impossible to achieve within the full app context in development (think certain loading or error states).
  2. Increase UI coverage: Enumerating all relevant states means you can be confident you’ve not missed anything and the component works in all possible scenarios.
  3. Target feedback: Looking it up in an explorer is a much easier way for a colleague to review a new or changed component; Focusing on one component at a time allows communication (especially between design and development) to happen with much higher precision.
  4. Build a component library: Supercharge component reuse within your app and organization.
  5. Parallelize development: Working one component at a time allows you to share tasks between different team members in a way that is just not possible at the level of “screens”.
  6. Test visually: Component explorers allow for a class of “visual” tests, analogous to traditional automated tests, in an area (UIs) that has often defied automated testing. In particular, they allow a form of “Visual TDD” that has the same benefits as TDD, but in the UI arena.
Our ideas are faulty, we have bugs

~ Fred Brooks

  1. Since ideas are prone to bugs, apps must be easily adaptable to accommodate new learning. Dissecting UIs into interchangeable components enables rapid reconfiguration of the pieces as business needs change.
  2. The component model encourages interchangeability by isolating component state from business logic. A component explorer makes this separation evident by providing a sandbox to develop the UI component in isolation of the app.
  3. The model also allows for parallel production where a team of people can work on different pieces of the UI simultaneously without distraction or state pollution from other parts of the app.
Your team gets things done faster

Process

  1. Build components in isolation
  2. Register the component with the explorer
  3. Specify state and stub data from within your component’s directory (e.g., a developer might use a factory to generate randomized data for your exampleListItem component or hardcode states they specifically want to test)

Test frontend behavior by specifying “states” a user can find themselves in. A progre

How to be Component Driven

Build one component at a time

Build each component in isolation and define its relevant states. Start small.

atom

Combine components

Compose small components together to unlock new features while gradually increasing complexity.

moleculue

Assemble pages

Build pages by combining composite components. Use mock data to simulate pages in hard-to-reach states and edge cases.

template

Integrate pages into your project

Add pages to your app by connecting data and hooking up business logic. This is when your UI meets your backend APIs and services.

website

Storybooks

Storybook is a tool for CDD UI development.
It makes development faster and easier by isolating components. This allows you to work on one component at a time.
You can develop entire UIs without needing to start up a complex dev stack, force certain data into your database, or navigate around your application.

storybooks

Introduction to Storybook
Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular
Storybook