Componentization

Introduction

Component is certainly a word you've heard in software development. It's a concept that can be used at different times and contexts.
Here we will focus on the component used to develop user interfaces (UI).

What are components?

The general concept of a component is: smaller parts of a whole.
Component concept in UI: parts of a layout or screen that can be reused.
Components ideally follow an important principle of software engineering: single responsibility. Each component should exist for a reason, and the clearer and more unique this reason is in the context of the application developed, the better.

It's also important to note that the componentization process (creating and defining components) can be very personal. We follow good practices and common concepts, but in reality, different developers mapping components of the same application can give different results, and all of them are correct.

This will depend on each developer's experience. But don't worry, there are concepts that everyone uses (or the vast majority) that can help you in the componentization process, and, together with practice, this will help you create your identity as a developer.

What is the expected result?

The first step is to look at the expected result.
In this step, you should look at the layout you want to achieve and start thinking about the structure of components (smaller parts) that you are going to create to make up your UI.
Let's start by looking at a simple layout example, a pet description page:

Imagine that this page is part of a system for vets and that your client wants to be able to view a pet's data in summary form, after clicking on one of the pets in a table.

Imagine that the application already exists and that you are only responsible for implementing this new functionality.
Now look at the elements on this screen that have a blue border:

These are the main components that together make up this screen. Now that we've identified the main components, we can think about their names and responsibilities:

Responsibilities:
(1) Pet photo: the only responsibility is to show the photo with the expected style (rounded edges, in the defined size (width and height)).
(2) Pet data card: the responsibility is to have the correct style with the selected animal's data.

The names of the components must be able to express their responsibility. In this case, I suggest the following names:
(1) ProfilePicture (or FotoPerfil in Portuguese)
(2) ProfileCard (or CartaoPerfil in Portuguese)

In the case of ProfileCard, it could also be just “Card”, but realize that this is a more generic name and would be correct if I intended to use this card in different places, not just in the profile.
There could also be a generic “Card” component whose responsibility would be to render any information in card format and which could also make it possible to define some custom styles, such as border rounding and background color.

This decision would involve the following question, considering the context of the project:

Are there other places in the application where I use a card?

• If so, I create a card that can receive any content and reuse this card to create the ProfileCard (more specific to the pet's profile) which would only receive the information needed for the pet's profile and would be responsible for presenting it in the correct order.
• If not, I could create only the ProfileCard, considering that if in the future I need a card similar to this one, but with a different data structure, I could create this generic Card and modify the ProfileCard to use this same Card.

Does this cover everything we need to show? Not yet. We also need a way of displaying the content. Notice that inside the ProfileCard we also have more parts (more components):

Note that I have listed all of them with the number 3, i.e. they are all instances of the same component reused for different contents, because, for this component, I see the following responsibility:

(3) Profile data. This component shows a pet's profile data in the expected style: it always has a title and content and can be center or left-aligned.

And about the name of the component:

(3) It would receive the name ProfileInfo (or InfoPerfil in Portuguese).

Notice that we have created a semantic for the components that make up the pet's profile: they all start with “Profile”. This makes it easier to identify which components are related and belong to the same context.

Where does this concept apply?

This concept applies to any tool that allows you to use componentization to create interfaces, for example: ReactJS, VueJs, Angular, and others.

Share

Would you do anything differently? Leave your suggestion here in the comments.

Exercises

In addition to understanding what the concept of components is, tips, and good practices, it is of the utmost importance that you practice so that you become more and more fluent in applying this concept.

So here are some layouts for you to practice the concept of componentization. Download the file and edit it by defining the name and responsibility of the components.

Note that the number of fields for component names and responsibilities is arbitrary and can be more or less than the numbers defined.

In a future post, I'll provide my answer to these layouts.

Feel free to share your results in the comments!