Angular: Core vs Shared Modules

Felix Costa
Blog do LFDev
Published in
4 min readAug 8, 2017

Uma grande feature que foi adicionada na versão Release Candidate 5 do Angular 2 foi a ideia de módulos. Com esse conceito em mente conseguimos pensar na aplicação de uma forma menor, com os componentes e de uma forma um pouco mais abrangente que aí sim seriam os módulos.

O Angular porém não te obriga a trabalhar com módulos e nem mesmo te obriga a trabalhar com eles de uma forma específica. Sendo assim, uma dúvida que logo pode aparecer no começo é: o que pode ser um módulo? E componentes que fazem parte da UI global como um Spinner, ficam em módulos? Como eu poderia organizar isso?

Pensando nessa forma de organizar nosso código, logo vi que as pessoas costumam armazenar componentes “globais” em módulos chamados Shared Modules, mas um tempo depois vi que também existiam pessoas trabalhando com uma outra ideia de organização, os Core Modules, e aí veio a dúvida: qual a finalidade de ambos e suas diferenças?

É importante citar que nenhum dos dois são “recursos” do angular. Tudo é baseado na ideia dos NgModules do angular. A discussão e a razão da existência desses dois termos é unicamente como forma de organizar seu projeto, separar suas responsabilidades e qualquer outro motivo que torne o código melhor manutenível.

Então vamos tentar entender quais seriam as ideias de cada um desses módulos que tem como objetivo final deixar nosso projeto mais organizado e até mesmo melhorar a manutenibilidade do app.

Shared Modules

Temos o Shared Modules para componentes que serão usados por Feature Modules (que são os nossos módulos específicos), como pela app em geral. Logo, esse módulo SOMENTE é importado por Feature Modules, não sendo importado nem pelo AppModule (nosso módulo principal) e nem mesmo pelo Core Module que iremos falar logo logo.

Geralmente definimos nesse tipo de módulo os nossos Pipes, Directives e templates de componentes em comum a aplicação. No ecossistema Angular esses componentes em comum são os “dumb components”, que podemos comparar com os Presentational Components no mundo React. São componentes que não trabalham com estados, interação com formulários ou qualquer regra mais complexa. Geralmente você define Input e Output properties, estilo e o template em si. Ser ou não um Dumb Component depende da sua responsabilidade e da sua arquitetura.

Uma outra utilidade interessante é que podemos usar o Shared Modules para importar outros módulos que são frequentemente usados em toda a app, como por exemplo, o FormsModule do @angular/forms. Isso te evita ficar importando dezenas dos mesmos módulos em cada Feature Module. Ao invés disso tu importa somente o Shared Module e pronto. Também é outra decisão que precisa ser levada em consideração porque pode não valer tanto a pena se o Shared Module contenha 10 módulos que são usados por todos os Feature Modules mas que também tenha 10 módulos que não são usados mas mesmo assim foram importados.

Core Modules

Se nos módulos compartilhados nos temos pipes, directives e etc, a ideia do Core Module é abrigar os Services globais e ele deve ser definido somente no AppModule da nossa aplicação. Isso garante que somente uma instância desses serviços será criada para toda a aplicação.

Uma vantagem de usar essa abordagem é percebida principalmente se você pretende utilizar Lay-Loading em seus Feature Modules. Isso porque como os módulos com lazy-loading são carregados sob-demanda os serviços acabam sendo re-criados e passados para esses módulos. Isso quebra a ideia de serem serviços globais de uma única instância global (Singleton instances).

Qualquer outro componente da sua aplicação que seja único e global pode ser adicionado a esse módulo, como por exemplo, um Sidebar, Um Header… são componentes que são globais a toda a aplicação, a depender do caso.

Uma última utilização interessante é que definimos tudo que antes iriamos definir em AppModule, dentro do nosso CoreModule. Isso mantém o nosso módulo principal limpo, deixando essa tarefa para um módulo centralizador.

Considerações

Eu achei essa forma de trabalhar bem interessante e tenho a adotado em minhas aplicações com angular. Caso tenha alguma opinião, crítica, sugestão ou erro, por favor, deixe nos comentários.

Referências

--

--

Felix Costa
Blog do LFDev

CTO at Sotero Tech. Passionate about code, web, clean code and challenges.