Desenvolvedores Angular, especialmente os mais novos, enfrentam um desafio constante: criar componentes e aplicações que sigam o princípio DRY (Don’t Repeat Yourself), ou seja, “não se repita”. O objetivo é construir soluções escaláveis e fáceis de manter. Para demonstrar esse processo, vamos explorar como transformar componentes repetitivos em componentes Angular reutilizáveis, e como a Directive Composition API pode levar essa reutilização a um novo nível.
Componentes Duplicados: Uma Abordagem Não-DRY
Imagine que você precisa criar placeholders de imagem para seis categorias diferentes: jogos, álbuns, filmes, móveis, relógios e sapatos. Uma abordagem inicial, mas pouco eficiente, seria criar um componente para cada categoria. Cada componente exibiria um placeholder de imagem específico para aquela categoria, com URLs seguindo um formato fixo, como https://dev.me/products/image-placeholder que pode gerar placeholders de imagem para seis categorias. Essa forma de codificar, embora direta, leva à duplicação de código e dificulta a manutenção.
Por exemplo, o componente para exibir um placeholder de álbum de fotos teria uma estrutura semelhante a esta:
Os outros componentes seriam quase idênticos, mudando apenas a URL da imagem. O componente principal, App, importaria e exibiria todos esses componentes individualmente. Essa solução, embora funcional, está longe de ser ideal, pois viola o princípio DRY. O sinal id, os métodos increment e decrement são duplicados em cada componente. E qualquer alteração na lógica ou na URL exigiria a atualização de todos os componentes, um processo demorado e propenso a erros.
No entanto, para resolver esse problema, podemos converter os componentes de placeholder de imagem para aceitar uma entrada de categoria, transformando-os em um componente reutilizável. Isso elimina a redundância e mantém o código limpo e fácil de manter.
Criando Componentes Angular Reutilizáveis
A chave para evitar a duplicação de código é criar um componente genérico que possa ser reutilizado para diferentes categorias. Em vez de ter seis componentes separados, podemos ter um único componente, AppPlaceholderComponent, que aceita uma categoria como entrada. Este componente usa a categoria fornecida para construir a URL correta do placeholder de imagem.
O componente AppPlaceholderComponent aceita um sinal de entrada subPath, que representa a categoria do placeholder de imagem. O componente App, por sua vez, importa o AppPlaceholderComponent e o utiliza em seu template. O template itera sobre um sinal de placeholders, passando a categoria para o componente para renderizar. Com essa abordagem, eliminamos os componentes redundantes e simplificamos a estrutura do código.
Com a refatoração, eliminamos os componentes AppAlbumPlaceholderComponent, AppMoviePlaceholderComponent, AppShoePlaceholderComponent, AppFurniturePlaceholderComponent, AppWatchPlaceholderComponent e AppGamePlaceholderComponent, substituindo-os pelo versátil AppPlaceholderComponent. Essa mudança não apenas reduziu o volume de código, mas também centralizou a lógica de gerenciamento de placeholders em um único local, facilitando futuras atualizações e manutenções.
Para mais informações, você pode consultar nosso artigo sobre novidades em tecnologia: MacBook Air, Mac Studio e iPads.
Essa solução é DRY, mas está fortemente acoplada aos placeholders de imagem de https://via.assets.so. E se quisermos renderizar os placeholders de imagem de https://picsum.photos? E se quisermos mostrar um botão que gera um ID aleatório em vez de dois botões que diminuem e aumentam o ID em 1? Deveríamos criar novos componentes para o site picsum.photos? A resposta inicial pode ser “sim”, mas podemos mudar para “não” após aplicar a Directive Composition API e as diretivas de host aos componentes de placeholder.
Usando a Directive Composition API
Para levar a reutilização de componentes ainda mais longe, podemos usar a Directive Composition API. Essa API permite adicionar funcionalidades a um componente através de diretivas, sem a necessidade de modificar o código do componente em si. Isso é especialmente útil quando você precisa de comportamentos diferentes para o mesmo componente em diferentes contextos.
Para demonstrar a Directive Composition API, vamos criar uma diretiva para carregar placeholders de imagem e um componente de botão que utiliza essa diretiva. Em seguida, vamos refatorar o componente AppPlaceholderComponent para usar essa diretiva e permitir a projeção de conteúdo, tornando-o ainda mais flexível e reutilizável.
Implementando a diretiva Placeholder Loader
Para usar a Directive Composition API, vamos adicionar novas diretivas e um componente AppPlaceholderButton. A diretiva PlaceholderLoaderDirective expõe dois sinais de entrada, variant e type, para aplicar as classes CSS ao botão host e emite um evento personalizado loadPlaceholder quando clicado. O seletor desta diretiva é opcional porque será usado como a diretiva host do componente.
Implementando a diretiva Image URL
A diretiva ImageUrlDirective expõe duas entradas, baseUrl e urlParam, que compõem o URL completo da imagem. O sinal computado url concatena as duas entradas para formar o URL da imagem. Esta diretiva foi criada para ser a diretiva host do componente AppPlaceholderComponent.
Para mais informações, veja este artigo sobre Chromebooks ganham recurso de pixel inteligente.
O componente de botão host
Este componente de botão importa a diretiva PlaceholderLoaderDirective no array hostDirective, que expõe as entradas e a saída. O componente injeta a diretiva PlaceholdeLoaderDirective e emite o evento loadPlaceholder ao clicar no botão.
Refatorando o AppPlaceholderComponent
O componente importa a diretiva ImageUrlDirective no array hostDirectives. Ele injeta a ImageUrlDirective e usa o sinal computado url como a fonte da imagem. Além disso, o template HTML substitui os botões HTML por para que se possa projetar o AppPlaceholderButtonComponent.
Adicionando serviços de placeholder de imagem
Para facilitar a troca de placeholders de imagem, podemos criar serviços que fornecem as URLs e os parâmetros necessários para diferentes sites. Por exemplo, podemos ter um serviço para o site https://dev.me/products/image-placeholder e outro para o site https://picsum.photos. Esses serviços encapsulam a lógica de construção das URLs e fornecem métodos para atualizar os placeholders.
Este serviço preenche os URLs de placeholder de imagem do site https://dev.me/products/image-placeholder. Os métodos incrementam ou diminuem o ID da imagem. Este serviço preenche os URLs de placeholder de imagem do site https://picsum.photos, e há um método que randomiza o ID da imagem entre 1 e 20.
Construindo os placeholders de imagem para ambos os sites
O componente App injeta o serviço DevMePlaceholderService para passar os URLs e parâmetros para o AppPlaceholderComponent para renderizar os placeholders de imagem. Em seguida, dois componentes AppPlaceholderButtonComponent são projetados para exibir os botões para carregar as imagens anterior e seguinte quando clicados.
O componente App injeta o serviço PicsumPlaceholderService para passar os URLs e parâmetros para o AppPlaceholderComponent para renderizar as imagens do picsum.photos. Em seguida, um componente AppPlaceholderButtonComponent é projetado para exibir um botão que carrega uma imagem aleatória quando clicado.
A Directive Composition API e a projeção de conteúdo permitem funcionalidade reutilizável e renderização de conteúdo dinâmico. A demonstração pode ser dimensionada para mostrar outros placeholders de imagem, passando os URLs e parâmetros da imagem para as entradas do componente e projetando botões de carregador.
Ao combinar a Directive Composition API com a projeção de conteúdo, criamos um componente AppPlaceholderComponent altamente flexível e reutilizável. Esse componente pode ser facilmente adaptado para exibir placeholders de imagem de diferentes sites e para fornecer diferentes tipos de interações, tudo sem a necessidade de modificar o código do componente em si. Essa abordagem promove a reutilização de código, facilita a manutenção e permite criar aplicações Angular mais escaláveis e eficientes.
Este conteúdo foi auxiliado por Inteligência Artificiado, mas escrito e revisado por um humano.
Via Dev.to