关于 Angular 应用 Components 和 Directives 的实例化问题

同 Angular Module 不同，Angular Components 和 Directives 要实例化多次，每个出现在 HTML template 中的 markup 都会对应一次实例化。

此外，这些项的作用域也限定在它们被导入的 NgModule中，以防止两个组件使用相同的选择器时发生命名冲突。由于依赖注入(DI)行为的这种差异，需要区分一个包含组件和指令的 NgModule 和一个包含组件、指令和 providers 的 ModuleWithProviders 是很有帮助的，这正是forRoot()方法进行区分的地方。

下面是 SAP Spartacus 关于 forRoot 方法的一个例子：

export class SiteContextModule {
  static forRoot(): ModuleWithProviders {
    return {
      ngModule: SiteContextModule,
      providers: [
        provideDefaultConfigFactory(defaultSiteContextConfigFactory),
        contextServiceMapProvider,
        ...contextServiceProviders,
        ...siteContextParamsProviders,
        provideConfigValidator(baseSiteConfigValidator),
        {
          provide: CONFIG_INITIALIZER,
          useFactory: initSiteContextConfig,
          deps: [SiteContextConfigInitializer, SiteContextConfig],
          multi: true,
        },
        ...contextInitializerProviders,
      ],
    };
  }
}

然而，依赖注入并不总是这么简单。有些时候，应用程序的所有ngmodule在引导过程中都不可用。延迟加载就是这样一个例子。当在路由过程中惰性加载NgModule时，在惰性加载的NgModule中注册的提供商及其子模块在引导过程中不可用，Angular 那时无法注册它们。因此，它们只有在加载路由时才会被添加为提供商，而且它们的作用域会从惰性加载的NgModule及其子模块开始注入。如果有多个惰性加载 NgModule 试图注册相同的提供商，那么 NgModule 树中的每个节点最终都会拥有不同的实例。通过在根目录下导入提供商，它有助于确保所有惰性加载的 ngmodule 都能获得该提供商的同一个实例，这也是forRoot() 被命名为该实例的原因。

总结

何时使用 Module 的 forRoot 方法？简言之，当一个库的 dependency 需要某个 module 时，就调用该 module 的 forRoot 方法，达到全局(globally)导入 providers 的目的。

在其他 ngmodule中，必要时使用 import 的非根形式来导入组件和指令。

当一个特性 NgModule 导出的组件和指令需要共享相同的自定义提供商实例时，请考虑用forRoot()方法在根NgModule中注册这些提供商。这有助于确保所有子ngmodule都能访问相同的提供商实例，而不需要使用者显式地处理提供商注册。