Component-Driven Development
Component-Driven Development builds UIs bottom-up from isolated, reusable components that are developed and tested on their own before assembly. It speeds delivery, improves reuse, and makes interfaces easier to test and document.
Organization
Tom Coleman / Chromatic
Published
Nov 1, 2017
Best Practice: Component-Driven Development
Component-Driven Development (CDD) is a process for building user interfaces from the bottom up, starting with individual components and progressively combining them into screens and full applications. Each component is built, viewed, and tested in isolation, independent of the application's data and backend. CDD became mainstream with modern component frameworks and tools like Storybook. It speeds up development, improves reuse, isolates bugs, and makes UIs easier to test and document.
Step-by-Step Implementation Guidance
- Break the interface into discrete, single-responsibility components.
- Develop each component in isolation with explicit props and states.
- Capture every meaningful state as a story or fixture, including loading and error states.
- Write unit and visual tests against components in isolation.
- Compose components into larger sections and then into pages.
- Connect data only at the composition layer, keeping components presentational where possible.
- Publish the component catalog as living documentation.
Common Mistakes Teams Make When Ignoring This Practice
- Building components tightly coupled to global state or API calls.
- Only testing components inside full pages, making failures hard to isolate.
- Skipping edge-case states like empty, loading, and error.
- Duplicating logic instead of reusing shared components.
- No catalog, so developers cannot discover what already exists.
Tools and Techniques That Support This Practice
- Storybook and Ladle for isolated development.
- Chromatic and Percy for visual regression testing.
- Testing Library and Jest or Vitest for unit tests.
- Design tokens and a shared component library.
How This Practice Applies to Different Migration Types
- Cloud Migration: Isolated components are portable across hosting and rendering targets.
- Database Migration: Presentational components with mock data are unaffected by schema work.
- SaaS Migration: Rebuild parity UI from a catalog when moving to a new platform.
- Codebase Migration: Migrate component by component, validating each in isolation.
Checklist
- UI decomposed into single-responsibility components.
- Components developed in isolation.
- All states captured as stories.
- Unit and visual tests in place.
- Data connected only at composition.
- Component catalog published.