在 Angular 2 子模块中强制服务实例化（AngularJS 运行块的替代方案）

我在子模块中有一个服务，它包装了一些第三方模块，实例化并初始化其服务以准备在应用程序中使用。

@Injectable()
class SubmoduleInitializerService {
    constructor (thirdPartyService: ThirdPartyService) {
      thirdPartyService.initialize(...);
      ...
    }
}

@NgModule({
    imports: [ThirdPartyModule],
    exports: [ThirdPartyModule],
    providers: [
        ThirdPartyService,
        SubmoduleInitializerService
    ]
})
class AppSubmodule {}

ThirdPartyService不直接注入到应用程序中，而是被其他应用程序使用ThirdPartyModule单位，所以只要SubmoduleInitializerService被注射到同一个注射器中ThirdPartyService或父注入器，一切都很好：

export class AppComponent {
    constructor(
      /* DO NOT REMOVE! BAD THINGS HAPPEN! */
      submoduleInitializerService: SubmoduleInitializerService
    ) {}
    ...
}

它被证明是一个糟糕的模式，因为原因尚不清楚SubmoduleInitializerService应保持注射状态AppComponent如果它既没有在类中也没有在模板中使用（已经被意外删除一次）。

基本上AppSubmodule模块需要 Angular 1.x 的替代品angular.module(...).run(...) block.

这里有哪些选项？

APP_INITIALIZER https://angular.io/docs/ts/latest/api/core/index/APP_INITIALIZER-let.html（未记录的）服务在 Angular 2 中很好地扮演了 AngularJS 配置/运行块的角色（不包括异步初始化的功能）。

对于只是急于实例化的 noop 初始化块SubmoduleInitializerService it is:

@NgModule({
    imports: [ThirdPartyModule],
    exports: [ThirdPartyModule],
    providers: [
        ThirdPartyService,
        SubmoduleInitializerService,
        {
            provide: APP_INITIALIZER,
            useFactory: () => () => {},
            deps: [SubmoduleInitializerService],
            multi: true
        }
    ]
})
class AppSubmodule {}

Since APP_INITIALIZER是多提供商的，它允许每个应用程序有多个初始化函数，这些初始化函数遵循模块加载的顺序。

对于同步初始化，更短（可能更合适）的替代方案是将服务注入到模块的构造函数中：

@NgModule({
    imports: [ThirdPartyModule],
    exports: [ThirdPartyModule],
    providers: [
        ThirdPartyService,
        SubmoduleInitializerService
    ]
})
class AppSubmodule {
    constructor(sis: SubmoduleInitializerService) {}
}

正如中所解释的这个答案 https://stackoverflow.com/a/43827191/3731501, APP_INITIALIZER与以下人员有一些共同特征config块，也是因为它用于在组件初始化之前配置服务并且容易受到竞争条件的影响（例如，因为APP_INITIALIZER用于配置Router，将其注入另一个APP_INITIALIZER将导致循环依赖）。