DEV Community: Bianca Camargo Machado

Componentization

Bianca Camargo Machado — Thu, 14 Nov 2024 17:05:11 +0000

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.

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!

Componentização

Bianca Camargo Machado — Mon, 11 Nov 2024 00:09:27 +0000

Contexto

Componente é certamente uma palavra que você já ouviu no mundo de programação de software. É um conceito que pode ser utilizado em diferentes momentos e contextos da área.
Aqui focaremos no componente que é utilizado para desenvolvimento de interfaces de usuário (UI).

O que são componentes?

O conceito geral de componente é: partes menores de um todo.
Conceito de componente em UI: partes de um layout ou tela que podem ser reutilizados.
Os componentes idealmente seguem um princípio importante da engenharia de software que é a responsabilidade única, ou seja, cada componente deve existir por um motivo e quanto mais claro e único este motivo é, no contexto da aplicação desenvolvida, melhor.

Também é importante ressaltar que o processo de componentização (criar e definir componentes) pode ser muito pessoal. Seguimos boas práticas e conceitos em comum, mas, na verdade, diferentes desenvolvedores mapeando os componentes de uma mesma aplicação podem chegar em resultados diferentes e ambos estarem corretos.
Isso vai depender da experiência e da forma de trabalhar de cada desenvolvedor. Mas não se preocupe, existem conceitos que todos utilizam (ou a grande maioria) e que podem te ajudar no processo de componentização e, junto com a prática, isto vai te ajudar a criar sua identidade como desenvolvedor.

Qual o resultado esperado?

O primeiro passo é observar o resultado esperado.
Neste passo você deve observar o layout que deseja atingir e começar a pensar na estrutura de componentes (partes menores) que você vai criar para compor a sua UI.
Vamos começar observando um exemplo simples de layout, uma página de descrição de um pet:

Imagine que esta página faz parte de um sistema para veterinários e que o seu cliente quer poder visualizar os dados de um pet de forma resumida, após clicar em um dos pets de uma tabela.

Imagine que a aplicação já existe e que você é responsável por implementar apenas esta nova funcionalidade.
Agora, observe os elementos desta tela que estão com uma borda azul:

Estes são os principais componentes que juntos formam esta tela. Agora que identificamos os principais componentes, podemos pensar no nome e responsabilidade deles:

Responsabilidades:
(1) Foto do pet: a única responsabilidade é mostrar a foto com o estilo esperado (bordas arredondadas, no tamanho (largura e altura) definidos).
(2) Cartão dos dados do pet: a responsabilidade é ter o estilo correto com os dados do animal selecionado.

Os nomes dos componentes devem ser capazes de expressar a responsabilidade deles. Neste caso, sugiro os seguintes nomes:
(1) ProfilePicture (ou FotoPerfil em português)
(2) ProfileCard (ou CartaoPerfil em portugês)

No caso do ProfileCard, ele poderia também ser somente “Card”, mas perceba que este é um nome mais genérico e seria correto se eu pretendesse utilizar este card em diferentes lugares, não só no perfil.
Ainda poderia existir um componente "Card" genérico cuja responsabilidade seria renderizar qualquer informação em formato de card e que poderia também possibilitar a definição de alguns estilos customizados, como arredondamento da borda e cor de fundo.

Esta decisão envolveria a seguinte pergunta, considerando o contexto do projeto:

Existem outros lugares na aplicação onde utilizo um card?

Se sim, crio um Card que pode receber qualquer conteúdo e reutilizo este Card para criar o ProfileCard (mais específico para o perfil do pet) que receberia apenas as informações necessárias para o perfil do animal e teria a responsabilidade de apresentá-las na ordem correta.
Se não, posso criar somente o ProfileCard, considerando que, se no futuro eu vier a precisar de um card parecido com esse, mas com uma estrutura de dados diferente, poderei criar este Card genérico e modificar o ProfileCard para utilizar este mesmo Card.

Isto cobre tudo o que precisamos mostrar? Ainda não. Precisamos também de uma forma de mostrar o conteúdo. Perceba que dentro do ProfileCard também temos mais partes (mais componentes):

Perceba que listei todos eles com o número 3, ou seja, todos são instâncias de um mesmo componente reutilizados para conteúdos diferentes, pois, para este componente, vejo a seguinte responsabilidade:

(3) Dado do perfil. Este componente mostra o dado de perfil de um pet no estilo esperado: sempre tendo um título e um conteúdo, podendo estar alinhado no centro ou à esquerda.

E sobre o nome do componente:

(3) Receberia o nome ProfileInfo (ou InfoPerfil em português)

Perceba que criamos uma semântica para os componentes que compõem o perfil do pet: todos iniciam com “Profile”. Desta forma, tornamos mais fácil de identificar, em meio a vários componentes, quais estão relacionados e pertencem ao mesmo contexto.

Onde este conceito se aplica?

Este conceito se aplica a qualquer ferramenta que permita utilizar componentização para a criação de interfaces, por exemplo: ReactJS, VueJs, Angular e outros.

Compartilhe

Você faria algo diferente? Deixe aqui nos comentários a sua sugestão.

Exercícios

Além do entendimento do que é o conceito de componentes, dicas e boas práticas, é de suma importância que você pratique para que fique cada vez mais fluente na aplicação deste conceito.

Então deixo aqui alguns layouts para que você pratique o conceito de componentização. Baixe o arquivo e edite definindo nome e responsabilidade dos componentes.

Note que o número de campos para colocar nome e responsabilidade dos componentes é arbitrário, podendo ter mais ou menos do que os números definidos.

Em um próximo post, vou disponibilizar a minha resposta para estes layouts.

Fique à vontade para compartilhar o seu resultado nos comentários!