Benefits Of Categorising Components By Use-Case
Tags: react, design, ux
Published: 2022-03-28 11:08:20

Organising things feels good. If you have a design system, you might have organised the components with categories.

Besides cleaner organisation, is there something that we can get out of good categorisation?

It turns out there's a lot.

## Meet the Categories

![Visualisation of different categories of components](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4htva0r81fkrt4xr29mc.png)

Over the years, these are the categories I've come up. This categorisation is based on use case. Almost all components fall into one of these.

- **Structural.**

  These are the visible or invisible components that provide structure to your app. Examples include `Stack`, `Grid`, and `Columns`.

- **Informational.**

  These components are used to display information to the users. They may display this information using text, icons, colors, and so on. Examples include `Badge` and `Tooltip`.

- **Input.**

  These components are used to get information from the users and often used inside a form. Examples include `TextField`, `AutoComplete`, `CheckboxList`, and `Select`.

- **Action.**

  These components are used to perform an action immediately. Examples include `Button` and `Menu`.

- **Feedback.**

  These components are used to provide a feedback as a response. Examples include `Toast` and `Progress`.

- **Navigational.**

  These components are used to provide navigational aid to the users. Examples include `Link`, `Breadcrumb`, and `Pagination`.

Let's go through the benefits of this kind of categorisation.

## Benefit 1: Clear Distinction

Often we find components used in a way they're not meant to be. A very common one is the use of dropdowns as menu of actions.

![Difference between a select and menu](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l3wxte7r6f6duhih4kau.png)

Depending on your designs, they may even look very similar. But functionally, they are different, and the astute among you would already know it.

If you try to sort them in one of the categories we saw before, they start making sense. One provides a menu to **input** a selection, but not act immediately upon it, while the other provides a menu for **actions** that happens immediately on selection.

Naming is hard and cannot be decoupled from opinions. In the wild, often they're called **select** and **menu** respectively. If you're looking to get insipred, the [Component Name Matrix](https://open-ui.org/research/component-matrix) is a great place to start.

![A link that looks like a button](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wp571pzb6fe1xqwopa9j.png)

Another common mistake is using a button that looks like a link to **navigate** to another page. Or using a link that looks like a button to perform an **action**. While it is okay to have such variants, categorising them thoughtfully can help you avoid misuse and help you write clear do's and dont's.

## Benefit 2: Precise Semantics

A lot of components that fall in the same category share semantic traits. Informational components like **Badge** and **Alert** display part of their information using colors, often called the tone of the information they're displaying. Similarly, actions share the nature of the action being performed.

![Using tonality instead of palette colors](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ampmu8m5vkkbijhhftkk.png) 

Once you have a category, you can easily find the components that share the same semantic traits and create semantic tokens for them.

## Benefit 3: Correct Features By Common Traits

Similar to how the category can surface the semantics of the components, it also helps in aiding the API design and features of a component. More precisely, what should and should not be in the API.

Going back to the example of **LinkButton** and **ButtonLink**. The former should support actional properties like `onClick` while the later should support navigational properties like `href`.

This can help you avoid common pitfalls found on the web. Like in this case, using a button as a link and vice-versa. Have you even tried opening a link in a new tab just to find out that you're looking at a button disguised as a link? It is a frustrating experience.

## Closing

I find this topic very interesting and certainly intend to write more in-depth posts on it. There's so much more to uncover.

![Common traits of various choice inputs](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ira1vpd80j9ajtyhfagf.png)

For instance, the input components **Select**, **CheckboxList**, and **RadioList** are all _choice_ components and could be used interchangeably depending on the space available, amount of choices, and ability to select multiple choices.

Once you start seeing the patterns, interesting facts emerge. And I hope to keep sharing them as I discover them.

Cheers!