Componentizando projetos em Angular

“Como organizo meu sistema em componentes?”

Photo by Markus Spiske on Unsplash

Desenvolvimento frontend cresceu muito ao longo dos anos, deixando de ser apenas as “telas com validações” para tornar-se eficientes sistemas, auxiliando o usuário em sua experiência, evitando bugs e problemas com a integração com o backend.

Algo que tem sido muito explorado é a organização por componentes. Pensar dessa maneira ajuda a “quebrar” o sistema em pequenas peças, que se encaixam de acordo com o necessário, mais ou menos como brincar de lego. A grande sacada é poder aproveitar as suas peças o máximo possível.

Entretanto, frequentemente quando estamos envolvidos nessa “brincadeira”, nos deparamos com algumas perguntas do tipo: “ok, preciso dividir tudo mesmo?”, “estou aproveitando as peças, ou apenas dividindo-as?”

Tudo precisa ser um componente?

Vamos começar a jogar essa partida de lego desse ponto. Respondendo a pergunta do título de imediato, não! não precisa, mas pode. Você não precisa fazer um componente para um botão, para um input e, assim sucessivamente, para cada item da tela. Você pode simplesmente inserir um tema de estilo principal que afeta o projeto como um todo.

Você só dividiria nesse nível, se de fato sua intenção fosse inserir certos comportamentos customizados nesses itens.

O que precisa de fato ser um componente, é o que no contexto do seu negócio vai ser reaproveitado em outras áreas do sistema. Agora, antes de continuarmos a explorar isso, temos que separar dois papéis importantes que nos levam ao próximo ponto.

Componentes de negócio x Componentes de página

Na minha experiência de desenvolver sistemas com Angular, a primeira coisa que precisa ficar bem clara na nossa mente é a diferença entre Páginas e Componentes, já que tudo em Angular é em si um componente.

Páginas são todos os componentes que possuem rota e utilizam-se de componentes menores, organizando-os adequadamente para a experiência do usuário ser a melhor possível.

Para ficar bem entendido, digamos que você está vendo uma tela que contém uma lista de carros e pode cadastrar um novo carro clicando num botão “novo carro”, como na imagem abaixo:

Nesse caso específico do exemplo, a página de carros é um componente de página. Ela possui uma rota para si e utiliza dentro dela um componente de “app-tabela-de-carros”, além de um botão que pode muito bem chamar um “app-modal-novo-carro”, ou direcionar à outra página que contenha um “app-form-novo-carro”, ou algo do tipo.

E os componentes de negócio? É o papel que o “app-tabela-de-carros” está desenvolvendo nessa página. Veja que essa tabela pode ser usada em qualquer outra página ou modal, ou o que sua criatividade permitir.

Separando esses dois tipos de componentes, podemos prosseguir com um exemplo de estrutura para auxiliá-lo na sua arquitetura.

Arquitetando seus componentes

Partindo do princípio de que nós concordamos que existem componentes de página e de negócio (caso contrário, você já deve ter ido embora), vamos dividir isso fisicamente na nossa arquitetura. Seria algo como na imagem abaixo:

Perceba que independentemente de estarmos falando de páginas ou de componentes de negócio, eles estão organizados por contexto. Agora, falando especificamente dos módulos, veja que há um “form-carro”, “incluir-carro” e também um “editar-carro”.

Distribuí dessa maneira para que o editar-carro e o incluir-carro pudessem utilizar esse mesmo formulário (form-carro) para integrar com os serviços de edição e inclusão, respectivamente. Os componentes de negócio podem ser também reaproveitados por outros componentes de negócio, como nesse caso.

Isso quer dizer que na página de criar carro eu precisaria utilizar o componente de negócio incluir-carro. Esse componente de negócio, utilizar o serviço adequado e o componente de form e, por fim, os integra.

Em grandes projetos a arquitetura acima ajuda de muitas formas. Alguns dos pontos são que:

• Visualizamos melhor o que são páginas e o que são componentes de negócio
• Conseguimos reaproveitar os componentes de forma mais efetiva
• Serviços, entidades e outras coisas do gênero possuem seu próprio diretório. Qualquer componente pode usar um serviço de qualquer outro contexto, se necessário
• Os testes unitários se tornam mais simples, partindo do princípio de que cada componente tem uma única responsabilidade. Ex: Form precisa apenas validar e exportar os dados quando válidos. O Incluir utiliza os dados do form e os conecta com o serviço de backend. Página renderiza os componentes necessários dentro de uma rota. etc…

Cuidados a serem tomados

Alguns cuidados devem ser tomados ao dividir componentes. Então, anote os seguintes pontos:

1 — Não encha seu componente de “if’s”

Ah! Como isso é importante. Entenda, se você está precisando adaptar seu componente com um monte de if’s para atender algo, é porque provavelmente você já passou da etapa de dividi-lo há muito tempo. A responsabilidade de cada componente deve ser única.

2 — Analise se você realmente vai reutilizar o que você está fazendo

Caso você não vá de fato usar esse componente em nenhum outro lugar, faz sentido separá-lo para uma “possível utilização”? Pense nisso.

3 — Sempre revise o que você está fazendo

Sempre que revisamos nosso trabalho, vemos que podemos fazer melhor. Não estou nem de longe pedindo para você ser perfeccionista, mas zeloso. Vai dizer que você não tem vergonha dos seus códigos de um ano atrás? Talvez até menos que isso. Ao revisar seus códigos, você provavelmente vai enxergar melhor o que tem um potencial para virar um componente e o que não faz sentido extrair.

4 — Rascunhe antes de sair codando

Às vezes um breve estudo antes de sair componentizando lhe dará uma melhor clareza de onde você quer chegar. Parece bobo, mas funciona.

5 — Observe projetos open source maiores

O Github é um acervo de projetos open source maravilhoso. Desses projetos, você pode e deve tirar boas ideias para aplicar no seu dia a dia. Não tenha medo de ler códigos dos outros. Vendo a nossa pequenez, nos tornamos maiores. Tenha esse entendimento, você sempre pode melhorar e sempre haverá pessoas melhores e piores que você, e está tudo bem!

E os componentes de UI (interface)?

Você pode muito bem criar um contexto “ui” junto com o carros e acessórios. Lá então você insere apenas componentes que lidam com o comportamento da interface. O princípio é o mesmo.

Mas quando falamos de UI, criar do zero coisas assim leva tempo! Seria bom você achar alguma Biblioteca que o auxiliasse nisso. Vou te dar um bom exemplo, anota isso aí!

Se você está trabalhando em algum projeto que precisa gerenciar informações, apresentá-las de forma eficiente ao seu cliente, tem uma boa dica para Angular. E tem mais, it’s free my friend. A licença permite você usar em qualquer projeto sem se preocupar, além de que a documentação é em português, open source e projeto é Brazuca! Acesse e dê uma olhadinha com carinho no PO-UI.

Concluindo

Espero ter te ajudado pelo menos um pouquinho a arquitetar seus componentes. Lembre-se que o objetivo de separar as coisas assim é te ajudar na reutilização de código. Se em algum momento as coisas estiverem confusas, pode ser que você tenha que rever se faz sentido para você a forma proposta neste artigo.