How to use .forRoot() within feature modules hierarchy

Can anyone please clarify to me how should I structure multiple nested feature modules hierarchy with .forRoot() calls?

For example what if I have modules like this:

- MainModule
- SharedModule
- FeatureModuleA
    - FeatureModuleA1
    - FeatureModuleA2
- FeatureModuleB

All feature modules has a .forRoot() static function.

How should I define FeatureModuleA with somehow "transfer" the .forRoot() functions?

@NgModule({ 
  imports: [
    //- I can use .forRoot() calls here but this module not the root module
    //- I don't need to import sub-modules here, FeatureA only a wrapper
    //FeatureModuleA1.forRoot(), //WRONG!
    //FeatureModuleA2.forRoot(), //WRONG!
  ],
  exports: [
    //I cannot use .forRoot() calls here
    FeatureModuleA1, 
    FeatureModuleA2 
  ]
})
class FeatureModuleA {
  static forRoot(): ModuleWithProviders {
    return {
      //At this point I can set any other class than FeatureModuleA for root
      //So lets create a FeatureRootModuleA class: see below!
      ngModule: FeatureModuleA //should be: FeatureRootModuleA 
    };
  }
}

I can create another class for root usage then set it within the forRoot() function of FeatureModuleA:

@NgModule({
  imports: [
    //Still don't need any sub module within this feature module
  ]
  exports: [
    //Still cannot use .forRoot() calls but still need to export them for root module too:
    FeatureModuleA1, 
    FeatureModuleA2 
  ]
})
class FeatureRootModuleA { }

But how can I "transfer" .forRoot() calls within this special ModuleClass?

As I see I need to import all sub-modules directly into my root MainModule and call .forRoot() for each there:

@NgModule({
  imports: [
    FeatureModuleA1.forRoot(),
    FeatureModuleA2.forRoot(),
    FeatureModuleA.forRoot(),
    SharedModule.forRoot()
  ]
})
class MainModule { }

Am I right? Before you answer please take a look at this file: https://github.com/angular/material2/blob/master/src/lib/module.ts

As I know this repo is maintained by the official angular team. So they solve the above by just importing all .forRoot() calls within a special MaterialRootModule module. I don't really understand how it would be applied for my own root module? What does the root and .forRoot really mean here? Is that relative to the package and not to the actual web project?

Solution 1:

Generally forRoot is used to add application/singleton services.

@NgModule({
  providers: [ /* DONT ADD HERE */ ]
})
class SharedModule {
  static forRoot() {
    return {
      ngModule: SharedModule,
      providers: [ AuthService ]
    }
  }
}

The reasoning is that if you add the AuthService to the providers in the @NgModule, it's possible for more than one to be created if you import the SharedModule into other modules.

I'm not 100% clear on whether the service would be created when the SharedModule is imported into an eagerly loaded module, but the explanation that the docs mentioned was in regards to lazily loaded modules. When you lazily load a module, all the providers will get created.

For this reason, we add a (by convention) forRoot method to signify that the method should only be called for the root (app) module, while for other module it should just be imported normally

@NgModule({
  imports: [SharedModule]
})
class FeatureModule {}

@NgModule({
  imports: [SharedModule.forRoot()]
})
class AppModule {}

Solution 2:

As forRoot intended only to provide singleton services, you can "re-provide" them explicitly in SharedModule:

@NgModule({})
class SharedModule {
  static forRoot() {
    return {
      ngModule: SharedModule,
      providers: [
        AuthService,
        FeatureModuleA.forRoot().providers,
        FeatureModuleB.forRoot().providers,
      ],
    }
  }
}

This way all the services will be provided by the SharedModule itself (not by respective sub-module) but it seems that it doesn't matter. Maybe someone can argue though...

Note, that FeatureModuleA can also "re-provide" singleton services from its sub-modules it similar manner.

Solution 3:

As mentioned above, lazy loaded modules are important to consider because a shared service could be used in a lazy loaded module, but if that service was already used and instantiated by another module, then there will be two instances hence the need for the singleton pattern. An AuthService is a great example here - you don't want to have one instance of the service with an unauthenticated user while another has "the same" user authenticated.

New to Angular 6 there is a new way to register a provider as a singleton. Inside the @Injectable() decorator for a service, use the providedIn attribute. Set its value to 'root'. Then you won't need to add it to the providers list of the root module, or in this case you could also set it to your SharedModule like this:

@Injectable({
  providedIn: SharedModule // or 'root' for singleton
})
export class AuthService {
...