Angular: one module for every component: antipattern?

Question

So I have encountered a practice where people will create a module for each component that has service dependencies. that way, when someone wants to use a given component, they dont have to read through the code to see what providers to add to the given module. is this an antipattern? will it cause performance issues or something?

Is there some recommended guidelines on lower/upper limits on how many components/directives/providers/etc should be in a given module? has there been testing of the angular/angularJs ecosystems with 100s of modules on a view? in comparison with if just regular components were all bundled in maybe like 20ish modules instead?

Squinch

Answer 1

Generally, there are different module types in Angular and guidance as to what they should contain and what modules should import them:

• Widget modules - Contains mostly UI components, but no services. Imported by Feature modules.
• Features modules - Contains domain-specific private components. Imported by AppModule.
• Service modules - Contains services exclusively. Imported by AppModule.
• Routed modules - A specialized Feature module, that is the target of routing.
• Routing modules - Contains navigation routes and resolver/guard services.

Modules can have dependencies on other modules. For example, a Widgets module could be expected to be used with a Services module, where AppModule imports the ServicesModule, and FeatureModule imports the WidgetsModule. The BrowserModule/CommonModule is an example of this pattern; so is RouterModule.forRoot()/RouterModule.forChild().

I would say its overkill to have one module per component. It would be hard to organize and group common functionality together and leverage services in any meaningful way. It could easily become unwieldy when your imports for a single module run into double-digits.

[Edit]

After re-reading this question, I would like to add a clarification because I think the one-component approach with NgModule encapsulation deserves more attention. I don’t believe in 1:1 module-to-component - that would be overkill. However, I am in full support of 1:many module-to-component where the module exports only one component, and all the other components are private to the module. This latter approach is known as NgModule encapsulation, and it is an excellent way to build your application in a way that loosely couples your top-level components.

Yodel

Answer 2

Practically, angular always prefer you to have basic module -

• Features module, Shared module, Routing module, Core module,

But if application is big it is better to have lazy loading for modules, to have module for every component is best option, which increase app speed along with this browser load that component which is required.

Poppy

Answer 3

If you have a relatively small app then bloating a single module is ok. Once your app starts to get relatively large then it makes sense to start lazy loading modules so your users don't have to download the entire build on app start. Grouping related functionality into modules makes things easier to maintain as well.

So for a smallish site, a single module will be fine but as your app grows it makes sense to start refactoring components and services into modules.

Reluctivity