Remove deprecated .forRoot() from the code

[maxokorokov]

Should have been removed in 4.0.0, but was forgotten.
Marked as deprecated since 3.0.0.

[benouat]

I am not really sure we should do it.

When animations will land #2817 we will have to introduce an API to globally configure ng-bootstrap.

A natural solution (at least to me) would be to use forRoot for that (or any other static method...)

@NgModule({
  imports: [
    NgbModule.forRoot({ enableAnimations: true })
  ]
})
export class AppModule {}

This solution is somehow used in plenty of other libraries:

• Angular Router with RouterModule.forRoot(routes, { options }) or RouterModule.forChild(routes)
• Ngrx with StoreModule.forRoot({ options }), EffectModule.forRoot([ effects here ]) or EffectModule.forFeature([ effects here ])

Also, knowing we deliver per-widget modules, we should also keep the same mechanism to allow people using only one or two widgets modules to also configure them.

@NgModule({
  imports: [
    NgbTypeaheadModule.forRoot({ enableAnimations: true }),
    NgbModalModule.forRoot({ enableAnimations: true })
  ]
})
export class AppModule {}

@maxokorokov @pkozlowski-opensource WDYT ? Maybe I am completely off topic here, and using raw DI would be enough... I don't know.

By raw DI I mean something like that

@NgModule({
  imports: [
    NgbTypeaheadModule,
    NgbModalModule
  ],
  providers: [
    /* Using a Token ? */
    { provide: NGB_CONFIG, useValue: { enableAnimations: true } },
    /* Using a Config Class ? */
    { provide: NgbConfig , useFactory: myNgbConfigFactory },
  ]
})
export class AppModule {}

Myself I prefer the .forRoot() over the DI.

[zamzowd]

@benouat Did you guys come up with a planned approach for how to take configuration values when registering the module, per your concerns written above?

[benouat]

@zamzowd nope 😞 not yet