Is nested modules bad in Angular?

Question

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 ?

Answer 1

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.