Configuration v/s Composition - Design Reusable Components
Tags: designsystem, designpatterns, webdev, react
Published: 2023-06-29 17:18:29

Hello folks!! In this article, we'll learn about how to design component APIs for your design system and make it reusable across different teams, fulfilling all the use cases in the most optimised way and following the design principles guidelines.

We'll look into the different approaches to building component APIs.

## **🎯** Component Requirements

While building a component, we'll consider into mind the different use cases and as we add more functionality, the complexity of components increases. So before building future-proof components let's first explore all the use cases:

Consider creating an **Alert** component which looks something similar to this:

![components](https://cdn.hashnode.com/res/hashnode/image/upload/v1687625535961/97aa8fb2-d1e6-4868-bb44-9f81ecd52d1d.png)

Let's first break down the entire component into smaller subcomponents.

![subcomponents](https://cdn.hashnode.com/res/hashnode/image/upload/v1688024154286/3497ce4e-643c-441b-bed9-973af265fada.png)

The **Alert** component consists of the following subparts:

1. **Title**
    
    It can be a `string` or may be optional
    
2. **Message**
    
    Message can consist of multiline text or any other component. So we can fix its type to `string | ReactNode`
    
3. **Action buttons**
    
    It consists of any component where input from the user is required. It may consist of multiple buttons, or any other component or might be an optional field.
    
    Its type is set to `ReactNode | undefined`
    
4. **Icon**
  - We can define any icon to be shown.
  - Along with the icon name, its position also matters. There might be a case when we need to show the icon to the right.
  - The icon can also vary based on size.

5. **Variants**
    
    ![variants](https://cdn.hashnode.com/res/hashnode/image/upload/v1688034492303/caaed915-383f-4c06-a1d6-cbd24d1e02ed.png)
    
    The alert component can come under multiple variants and based on the type of variants colours, the font style of its subparts (title, message, icon) changes.
    
6. **Patterns**
    
    As some of the subparts are optional in the Alert component and the user can also add its custom component, this will result in multiple patterns.
    
    ![patterns](https://cdn.hashnode.com/res/hashnode/image/upload/v1688035513460/a3b6b2f8-d969-4e2f-9fe0-41645c98aacf.png)
    
    Now that we had go through all the requirements, let's move to the code part.
    

## **🎯** Configuration

> In the Configuration approach, the user can pass data to the component via props, and the component should know exactly how to render itself based on that props.

Let's move with the above example of the Alert component and see how to design its API using a configuration approach.

```javascript
const Alert = (props) => {
    const {
        title,
        description,
        actions,
        iconName, 
        iconSize, 
        iconPosition='left', 
        iconColor, 
        variant 
    } = props;

    return (
        <div className={variantClass}>
          {iconName && 
            <Icon 
              name={iconName} 
              size={iconSize} 
              position={iconPosition} 
              appearance={iconColor} 
            />
          }
          <div>
            {title && <Heading>{title}</Heading>}
            {message && <Paragraph>{description}</Paragraph>}
            {actions && (
              <div>{actions}</div>
            )}
         </div>
        </div>
            
    )
}

export default Alert;
```

Users can use this component using the following API:

```javascript
<Alert 
  title='Title goes here'
  description='Message goes here'
  variant='warning'
  iconName='warning_check'
  iconPosition='right'  
  actions={
    <div>
      <Button>Action 1</Button>
      <Button>Action 2</Button>
    </div>
  }
/>
```

As you notice, for all the functionality user needs to pass a prop to the component but all the design decision and rendering is handled internally by the component.

### 📍 Pros:

* Quick and easy to use. Different functionality and visual variants can be controlled by configuring props.
    
* Configuration API via props makes it harder to diverge from the design system and keeps the UI and behaviour consistent.
    

### 📍 Cons:

* Adding more features requires more props and conditional logic. Thus a component becomes harder to maintain.
    
* Not easy to extend.
    
* Not easy to override
    
* If a component can't be extended, a new version might need to be built.
    

Using the above approach, the user does not need to worry about the design consistency across the app, they simply need to pass the prop to the component and all the design and visual aspects need to be handled by the component internally.

But it may be overhead as sometimes props provided by the component are not enough to satisfy all the use cases and the user may want some kind of customisation. Also for each functionality providing a different prop may to lead complex APIs which are not easy to extend.

Let's explore another approach for a similar use case.

## **🎯** Composition

> In the Composition approach, Users should be able to take small building blocks and combine them together in whatever order they like.

Using this approach, the user is provided with multiple subcomponents which can be used in whatever order as per their use cases. Let's look at an example for better understanding.

```javascript

<Alert variant='warning'>
    <Alert.Container>
        <Alert.Title>
            Title goes here
        </Alert.Title>
        <Alert.Description>
            <div>Hello World!!</div>
            <Badge>Description</Badge>
            <Paragraph>Short Description</Paragraph>
        </Alert.Description>
        <Alert.Action>
          <div>
            <Button>Action 1</Button>
            <Button>Action 2</Button>
          </div>
        </Alert.Action>
        <Alert.Icon name='warning_check' />
    <Alert.Container>
</Alert>
```

In the above code, instead of passing multiple props, the user can use smaller subcomponents for customisation. For example, Instead of passing a description as a `string` they can also pass a custom-designed description as per their use case. And also change the position of the icon to the right.

All these are just building blocks which are used to **compose** the functionality based on different use cases.

### 📍 Pros:

* Extremely flexible
    
* It's easy to create different functionality and UI variants and add new building blocks.
    
* Makes a component library much more resistant to change
    

### 📍 Cons:

* You need to compose the building blocks yourself to create a fully functioning component/feature.
    
* Takes more time and code.
    
* It's easy to diverge from the design system and ship inconsistent UI and behaviour.
    

## **🎯** Which Approach to use?

Both approaches as we see above have their advantages and disadvantages. Then the question is which one to use and when?

The approach you want to use totally depends on your use case and design pattern. There might be cases when we can use both approaches to satisfy our use case appropriately.

## **🎯** Summary

The **Composition** approach offers more flexibility, but it does require more knowledge of how to compose the building blocks and how they work.

On the other hand, the **Configuration** approach is less flexible, but it is simpler to use and makes it easier to stick to the design system.

## **🎯** Wrap Up!!

That's all for this article. Thank you for your time!! Let's connect to learn and grow together. [**LinkedIn**](https://www.linkedin.com/in/anuradha-aggarwal-4a2751107/) [**Twitter**](https://twitter.com/Anuradh06359394) [**Instagram**](https://www.instagram.com/blogcode404/)

[![Buy-me-a-coffee](https://cdn.buymeacoffee.com/buttons/v2/default-blue.png)](https://www.buymeacoffee.com/anuradha2612)