CODEWITHSUNDEEP
angulartypescriptangular2-cliangular2-modules
orhun.begendi
orhun.begendi

Reputation: 937

Is nested modules bad in Angular?

There is something I wonder about modules. I started Angular 2 a while ago, so i search too many topics but I couldn't find any satisfying answer yet.

When we creating angular 2 application, using modules for sure. Also use nested modules of course. How many nested modules that we can use ? Is this doable or is there a limit for nested modules ?

For example lets say i got admin dashboard application. Can we build like this

app.module.ts
|
 --dashboard
    |
    --dashboard.module.ts
      |
      --login
        |
        --login.module.ts
        .
        .
        .

We can struct with that way for sure. But lets say we have 5 or more nested module, is it ok for angular application? Can cause any problem or cause any performance problem ? Or we should keep it simple (max 3 nested etc.) for practice ?

Also how tsc is behaving when nested modules and components as long as it increases ?

For summarize what is the pros, cons nested modules etc. and what is best practice for nested module structuring ?

Upvotes: 10

Views: 11390

Answers (2)

Hossam El-Deen
Hossam El-Deen

Reputation: 1122

For me, the main goal of using NgModules at all is lazy-loading; I'm not a fan of logical/feature structuring in angular. If there was no lazy-loading in angular, I'd probably just structure the code this way:

components/
services/
pipes/
models/
...

Lazy-loading-wise, nesting modules vs not nesting them makes no difference. And I probably decide which code is loaded together by which code is on the same page. For instance, even if 2 components feel like they belong to the same feature but they're on different pages, I'd want them to be on their respective pages' modules for better lazy-loading.

So, I currently structure my code this way:

app
|
 --services/
   |
    -- the services module called `CoreModule` in angular docs.
 --shared/
   |
    -- the shared module described in angular docs. Has models as well.
 --pages/
   |
    -- page1/
       |
        -- a module for page1/feature1 that I'll use in lazy-loaded manner (but may not do so if found unsuitable).
    -- page2/
       |
        -- a module for page2/feature2 that ...

So, answering your question in specific about nesting:

  • Nesting modules is actually just a folder structure; there's no effect vs non-testing angular-wise. A nested module is just like a top-level module. E.g., you can import login.module.ts in a module beside dashboard.
  • Since it's a folder structure, there's no limit on the levels of nesting angular-wise.
  • However, usually in nested modules, you have a module X importing a module Y importing a module Z, ... etc. For this point, I don't if it has effect on performance or no but I don't expect it to have. Especially that the same situation exists in library dependencies: imaging using an angular component/module from some npm package that uses another angular component/module in another npm package, ... etc.
  • For my opinion on nesting modules & code structure in general, I've outlined it above.

As a source for avoiding nesting, see "Do keep a flat folder structure as long as possible" principle in Angular's official Style Guide. In general, the Style Guide seems a good place for similar questions (just discovered it!).

Upvotes: 4

snorkpete
snorkpete

Reputation: 14574

Nested or not nested is not a black and white situation. Unfortunately, as for most of software development, "it depends."

However, I'd urge you to consider this - the point of the NgModule (besides the technical motivation of allowing AOT) is to provide a higher level 'unit' for your application. In other words, you can group individual components/services/pipes into discrete groupings that allow you to treat that grouping as a single unit that provides a certain amount of functionality. In most cases, this is used to provide features in your application (so called 'feature modules'), but the NgModule system is also used to provide other types of cross-cutting concerns. In fact, it becomes easy for library authors to distribute their library as a single NgModule, encapsulating all the functionality that they provide. (Examples include built-in libraries such as HttpModule and FormsModule, but also MaterialModule, FlexLayoutModule, etc.)

This use case of thinking of NgModule as a distribution container helps me think of how I should group my components/services/pipes - it's not always possible, but I try to think that I can take a folder containing the module definition and its various parts and should be able to drop that folder into any other application and it should basically work (assuming the presence of its external dependencies). Thinking of it this way helps to focus me on how granular to make the NgModule. This is not to say I don't nest folders within that NgModule, but just because there's a folder nested doesn't automatically mean I create a NgModule - unless the items make sense as a distribution container of some sort, I won't bother to create nested NgModules just to match the folder structure.

To summarize, your folder structure doesn't automatically mean you create NgModules for the deeply nested folders - and as such, there probably isn't a need for a deeply nested NgModule setup.

Upvotes: 19

Related Questions