The basics

Component driven development

Component-driven development (CDD) is an approach to development where the application is broken down into small, reusable, and independent components. Each component represents a specific piece of functionality or user interface, and they can be combined to build complex applications.

You want to build websites and applications in this bottom-up approach where small, repeatable user interface or functional elements are identified and made into components. While there is a technical aspect to this, this article focuses on the mindset attached to component-driven development rather than the details in the delivery.

This mindset does not have to start at the development stage. Understanding component-driven development at all stages helps us to sell, design, develop and support our applications and websites.

Benefits of component-driven development

There are many benefits to component-driven development, some might be obvious and others might be less so. Here are some of the benefits that we have found:

Reusability

Components are designed to be self-contained and independent, making them highly reusable across different parts of the application or even in entirely different projects. This reduces redundancy in code and development time.

Modularity

The modular nature of components allows developers to work on different parts of the application simultaneously without stepping on each other’s toes. It also makes it easier to test and maintain the codebase.

Consistency

By using standardized components, the application’s user interface and user experience remain consistent throughout the project. This leads to a better overall user experience and reduces confusion for users.

Scalability

Component-driven development makes it easier to scale an application as it grows. New features can be built by combining existing components, and the overall architecture remains manageable.

Collaboration

Since each component can be developed and maintained independently, it encourages collaboration among developers. Different teams or individuals can work on different components concurrently without much interference.

Encapsulation and Abstraction

Components encapsulate their internal logic, making it easier to understand and manage complex functionality. Abstraction allows the internal implementation details to be hidden, promoting a clear separation of concerns.

Testing and Debugging

Components can be individually tested, which simplifies the debugging process and allows for more efficient testing strategies. Isolated testing also reduces the likelihood of bugs and improves the application’s overall stability.

Rapid Development

Component-driven development accelerates the development process by enabling developers to use existing components rather than building everything from scratch. This speeds up the development cycle and time-to-market for projects.

Design Systems

CDD aligns well with the concept of design systems, where a consistent set of UI components and guidelines are used throughout an organization’s projects. This creates a unified design language and brand identity.

Adaptability to Changing Requirements

Components can be easily replaced, modified, or extended, allowing the application to adapt to changing requirements and business needs more effectively.

The anatomy of components

Credit: https://www.componentdriven.org/

Build one component at a time

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

Avatar Button Input Tooltip
Combine components

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

Form Header Card Table
Assemble pages

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

Home page Settings page Login page
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.

Web app Landing page Docs site

Although they may sound similar, Component Driven Development (CDD) is separate from Squiz’s Component Service. Component Service is used to build, deploy and manage components within the Squiz DXP, while CDD is a concept. Components Service might follow a CDD paradigm, where smaller “components” make up the deployed Component Service component, but they do not have a one-to-one relationship.

CCD tips

If done right CDD can be a powerful tool in your development arsenal. Here are some tips to help you get started:

Keep it simple

Often, as developers we try to do too much, we try to cram every configuration option into a single component. This can lead to a bloated component that is hard to maintain and difficult to use. Instead, try to keep your components simple and focused on a single task.

It’s okay to have two or more components that do similar things, often this is better than a bloated component that tries to do too much. Components can share smaller, common components or functions.

It’s important to stay DRY (Don’t Repeat Yourself) so if there are commonalities between components pull that part out as its own micro component.

Keep it self-contained

Components should be self-contained and independent of each other. This means that they should not rely on global variables or functions outside of their scope. This makes it easier to test and maintain the codebase.

Having self contained components also makes it easier to reuse and share them in other projects or applications.

Keep it consistent

Components should follow a consistent naming convention and coding style. This makes it easier for developers to understand and maintain the codebase.