DEV Community

Cover image for Angular: Quando os componentes precisavam de um módulo para chamar de lar
Douglas Garrido
Douglas Garrido

Posted on

Angular: Quando os componentes precisavam de um módulo para chamar de lar

Photo by Ryan Quintal on Unsplash

Angular mudou e continua mudando... Antes, um componente precisava ser declarado dentro de um NgModule para "sobreviver". Agora, ele simplesmente existe — de forma autônoma.

Sempre tive aquela analogia de que os componentes no Angular viviam dentro de caixas chamadas módulos, que por sua vez se encaixavam em outras caixas maiores, como o AppModule. No fim, tudo era uma grande construção de peças interconectadas, como um LEGO® bem estruturado.

Mas tudo isso começou a mudar a partir da versão 14 do Angular, quando os chamados componentes autônomos (standalone) foram introduzidos como uma funcionalidade experimental. Na versão 15, essa abordagem foi estabilizada e passou a fazer parte oficial do ecossistema.

E com isso vem mais uma linha de aprendizado, pois tudo muda, o componente deixou de depender de um módulo para existir. Agora ele importa o que precisa e já entra no jogo. Isso é genial e agiliza muito nosso trabalho como desenvolvedor.

Não vou entrar em detalhes sobre como eles funcionam ou como migrar seu projeto, mas se quiser saber mais, recomendo a excelente documentação oficial:
👉 Angular Standalone Doc's.

Este post traz meu ponto de vista — posso estar errado, mas estou aprendendo com o processo. E essa é a nossa vida como programadores: em constante evolução.

Mudança de paradigmas

Antes, tudo precisava "pertencer" a algo. Agora, não mais. É uma mudança profunda na arquitetura, e ao mesmo tempo, um pouco perigosa.

Se buscarmos sobre arquitetura standalone na web, irão aparecer diversas coisas, desde estruturas de redes, até mesmo hardware e aplicações. E o conceito disso tudo é trabalhar/operar independente de outros componentes ou funcionalidades.

No Angular, essa independência ficou clara. O componente não precisa mais estar dentro de um módulo. Porém, mesmo antes dessa mudança, boas práticas já nos incentivavam a criar componentes reutilizáveis, evitar repetição de código e organizar o projeto por features. A ideia sempre foi manter uma estrutura clara, escalável e de fácil manutenção.

De certo modo, muitos de nós já construíamos componentes "autônomos". E a forma como a equipe do Angular implementou essa mudança foi tão suave que a migração nem doeu. Para ajudar ainda mais, criaram um comando específico na CLI para facilitar essa transição:

ng generate @angular/core:standalone
Enter fullscreen mode Exit fullscreen mode

O lado bom... e o lado perigoso

Liberdade é bom — mas exige responsabilidade. Com a facilidade de criar componentes independentes, também vem o risco de gerar duplicação de código ou componentes que fazem a mesma coisa com pequenas variações. Claro, isso poderia acontecer também com módulos, mas a flexibilidade maior pode gerar desorganização, especialmente em equipes grandes.

Conclusão

Não tenha medo de atualizar seus projetos. Tenha medo de uma arquitetura ruim, que só vai piorar com o tempo. O Angular continua evoluindo, e embora algumas mudanças pareçam assustadoras no começo, a longo prazo elas tornam o desenvolvimento mais simples, mais rápido e mais poderoso.

No fim das contas, o Angular não ficou mais simples — ele só ficou mais direto. E como tudo em programação, a liberdade só vale a pena quando vem acompanhada de responsabilidade.

Top comments (0)