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:

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):

. 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!