Um guia completo para Angular componentes autônomos

Se há uma estrutura que não deixa pedra sobre pedra quando se trata de mudar e aprimorar o processo de desenvolvimento, é Angular. Com a versão mais recente do Angular 16.0.0, agora há alguns avanços importantes em coisas como ferramentas, renderização do lado do servidor e reatividade. E para mim, a introdução de Angular API autônoma é uma das maiores melhorias na versão mais recente que traz muitas vantagens para a comunidade de desenvolvedores. O novo recurso chamado Schematics for Standalone Components, em particular, parece estar renovando nossa capacidade de criar elementos e bibliotecas de interface do usuário reutilizáveis, eliminando módulos clichês ao mesmo tempo.

E isso não está mudando o jogo significativamente?

Mas vamos nos aprofundar nos Componentes Angular Autônomos (SACs) para entender melhor toda a empolgação em torno deles, bem como como exatamente eles funcionam, como criá-los, o que mudou desde Angular 14, quando o conceito de componentes autônomos foi apresentado pela primeira vez e assim por diante.

O que é um componente autônomo no Angular ou isso é um adeus ao NgModules?

A maneira mais curta de defini-los é que os componentes autônomos nos permitem construir Angular aplicativos sem usar módulos. Como não estão vinculados a nenhum módulo específico, podem ser usados em qualquer parte do aplicativo. Isso significa que as classes autônomas não precisam ser declaradas em um NgModule, portanto, temos menos código clichê.

Basicamente, os componentes autônomos não são obrigatórios. Recomendado sim, mas não obrigatório. No entanto, Angular recomenda sempre usar componentes autônomos, pelo menos para novos componentes que você criar. Eles são simplesmente mais agitáveis e menos caldeira. Você pode misturar componentes e módulos independentes. Concordo que podemos usar componentes autônomos em vez de módulos, pelo menos daqui para frente, mas se você decidir deixar o resto do seu componente modularizado, essa não é uma má decisão.

No Angular 14, a ideia de componentes autônomos foi introduzida junto com APIs autônomas – uma prévia do desenvolvedor na época. Eles se referiam a um tipo de componente que não fazia parte de nenhum módulo e poderia ser usado independentemente sem ser aninhado em outros componentes. Por outro lado, quando você queria fazer um componente antes disso, normalmente teria que passá-lo para dentro da matriz de declaração do módulo.

Então, o conceito começou a mudar e o processo de desenvolvimento evoluiu gradualmente.

A documentação oficial do Angular, por exemplo, estipula que "componentes, diretivas e pipes autônomos visam simplificar a experiência de criação, reduzindo a necessidade de NgModule. Os aplicativos existentes podem adotar opcional e incrementalmente o novo estilo autônomo sem nenhuma alteração significativa."

Em outras palavras, temos simplificação aqui.

Agora, com o Angular 16, obtemos oficialmente o recurso Esquemas para componentes autônomos e componentes autônomos projetados para serem independentes, modulares e reutilizáveis. Mas por que usar componentes autônomos no Angular? Embora eles não estejam substituindo completamente o uso de NgModules, eles nos permitem utilizar uma nova maneira de criar código modular e reutilizável. Ao longo do caminho, alcançamos até mesmo melhor capacidade de manutenção e capacidade de teste para nossos aplicativos Angular, além de uma estrutura de projeto que permanece intacta.

Esta é uma ótima alternativa!

Mas, novamente, os componentes autônomos no Angular não são um substituto, mas uma alternativa aos NgModules.

Que outros benefícios Angular componentes autônomos existem?

Aqui estão mais alguns motivos para usar componentes autônomos no Angular:

• Eles são a solução leve que pode efetivamente eliminar a classe e todos os outros excessos que a acompanham.
• Capacidade de adotar uma API mais funcional em comparação com a API baseada em classes muito mais pesada que costumava ter.
• Agora podemos carregar lentamente o componente diretamente sem um NgModule.
• Eles vêm com a capacidade de encapsular a funcionalidade e promover a reutilização de código em todo o aplicativo sem causar possíveis bugs com outros componentes.
• Não há mais necessidade de um AppModule, pois podemos inicializar o aplicativo com um componente.
• O roteamento em componentes Angular autônomos agora é mais instável em árvore, para que possamos apontar diretamente para um componente roteado ou configuração de rota.
• Eles podem importar facilmente outros componentes autônomos, diretivas, pipes e NgModules existentes também.
• Cada componente tem seu próprio arquivo (modelo, estilos, código TypeScript), resultando em uma estrutura de código muito melhor.
• Você projeta componentes com a reutilização em mente e pode facilmente adicionar novos recursos ou estender as funcionalidades existentes.
• Você pode escrever testes de unidade especificamente para cada componente autônomo Angular.

Como criar um componente autônomo no Angular?

1. Creating them

Criar seu primeiro componente autônomo é super fácil e acontece usando o sinalizador –-standalone. Mas primeiro, certifique-se de estar no Angular 16.

        2. Using them

Você pode usar um componente independente de duas maneiras:

• Em outro componente autônomo, simplesmente passando-o para a propriedade imports do mesmo componente autônomo.
• Ou dentro de um Módulo, passando-o para o array imports.

Usando componentes independentes com Ignite UI for Angular

A partir do Angular 16 e Ignite UI for Angular 16.0, agora você pode simplesmente adicionar as importações que seu componente autônomo precisa na propriedade imports. No exemplo a seguir IGX_GRID_DIRECTIVES pode ser usado para importar todos os componentes e diretivas relacionados à grade. Veja como criar e usar um componente autônomo no Angular com Ignite UI.

import {IGX_GRID_DIRECTIVES} from 'igniteui-angular';

@Component({  
   selector: 'app-grid-sample',
   styleUrls: ['grid.sample.scss'],
   templateUrl: 'grid.sample.html',
   standalone: true,
   imports: [IGX_GRID_DIRECTIVES, AsyncPipe] 
})

Você também pode importar todos os componentes usados pelo componente autônomo individualmente. Um exemplo com IgxGridComponent e IgxColumnComponent, quando apenas esses dois são usados por outro componente, é o seguinte.

import {IgxGridComponent, IgxColumnComponent} from 'igniteui-angular'; 

@Component({  
   selector: 'app-grid-sample',
   styleUrls: ['grid.sample.scss'],
   templateUrl: 'grid.sample.html',
   standalone: true,
   imports: [IgxGridComponent, IgxColumnComponent, AsyncPipe] 
})

Todos os componentes Ignite UI for Angular agora são exportados como componentes independentes. A biblioteca ainda exporta NgModules, que foram preservados para compatibilidade com versões anteriores, mas eles não declaram mais nenhum dos componentes Ignite UI for Angular.

Em vez disso, eles apenas importam e exportam os componentes autônomos. É importante observar que os componentes autônomos ainda estão em um estágio de visualização. Algumas exportações de diretivas de utilitários podem mudar no futuro e podem estar ausentes da documentação na versão inicial, portanto, o estado de visualização do recurso.

Quais são algumas das práticas recomendadas para Angular componentes independentes?

Ao trabalhar com Angular componentes independentes, você pode seguir várias práticas recomendadas para garantir um código limpo, sustentável e reutilizável, bem como projetos de próximo nível.

• Considere o tamanho do seu projeto e código

Como primeiro passo, considere o tamanho do seu projeto e como seu código está organizado. Você pode ler que não há alterações significativas relacionadas à migração de componentes regulares para autônomos se você apenas alternar todos os seus componentes para autônomos. No entanto, posso garantir que você introduzirá alguns bugs importantes em seu aplicativo. Mas talvez você não queira migrar todo o seu código para componentes autônomos. Agrupar componentes em um módulo e exportar apenas alguns deles é um padrão perfeitamente correto. Como você traduziria isso para componentes independentes? Em vez de um ngModule, você terá que configurar uma API usando barrelfiles, enquanto protege os componentes privados com regras de linting. Nesse caso, os componentes autônomos não necessariamente facilitam o gerenciamento de um projeto.

Portanto, se o tamanho do seu projeto for de médio a grande porte, meu conselho é iniciar essa migração bem devagar e apenas migrar todo o SCAM (Single Component Angular Module). Com o SCAM, um NgModule declara apenas um componente. Como eles já estão separados, você pode se acostumar a criar e trabalhar com componentes independentes a partir de então.

• Migrar Pipes & Diretivas

Outra boa prática é migrar todos os seus pipes e diretivas para componentes independentes. Dessa forma, você pode simplificar e reduzir alguns dos módulos.

• Ajuste e melhore continuamente o código

Depois disso, dê a você e sua equipe tempo para ajustar e melhorar continuamente sua base de código durante uma refatoração regular de código. Porque em um projeto de tamanho empresarial, a migração para componentes autônomos será um grande empreendimento. Ao fazer isso, você pode garantir que nenhuma regressão seja introduzida, enquanto todas as alterações são bem testadas e revisadas por seus colegas.

Em conclusão...

O argumento de que os componentes autônomos removem muitos clichês para mim é apenas parcialmente verdadeiro. A criação de um módulo não é mais necessária. Em vez disso, quase todos os componentes precisarão importar pelo menos CommomModule para que Angular funcionem conforme o esperado. Para casos mais complexos, uma lista bastante longa de outros módulos e componentes também terá que ser importada. Em alguns casos, então, isso leva a instruções de importação muito longas e, quando você abre um arquivo, deve rolar uma página inteira para realmente ver o código do próprio componente.

Não há uma resposta fácil para esta questão. Foram feitas sugestões para cortar o CommonModule para que você só precise importar o que é necessário, mas isso pode facilmente levar a uma longa lista de importações. Uma alternativa poderia ser que certos recursos, como a diretiva *ngIf, sejam importados por padrão. Atualmente, não há planos concretos da equipe Angular nessa direção.

Portanto, não há nada de errado em permitir que ambos os conceitos vivam juntos na base de código do seu projeto por algum tempo e ver como seu projeto continuará a evoluir e o que exatamente funcionará melhor.