Ngx-bootstrap: Modules and Angular Lazy Loading

[bogacg]

Right now, in order to make ng2-bootstrap modules work, I have to add in app.module with .forRoot() and then also in my lazy loaded module (without .forRoot()).

If a module is added root level, there shouldn't be need to add it again in any feature/lazy loaded module.
Also, I'm pretty sure most ng2-bootstrap modules can be implemented without need to be added in root level.

I haven't checked source code, and I respect your work a lot, so I don't want to make a strict comment like "this is wrong", but it didn't seem right to me either.

[SiasMey]

This is relevant to your question but unfortunately I dont have a great source or decent testing to confirm this.

Providers are always shared app wide.

Lazy loaded modules however, have a separate module context AFAIK. This is however specific to lazy loaded modules, feature modules do share the root module context.

[valorkin]

@bogacg to be honest, I don't like current situation
I need to figure out best way to use module.forRoor.forChild
but it will be later, if you have a good sample, I would love to take a look
thanks in advance

[1-0-1]

+1

[SiasMey]

This is simply my understanding, but at a high level this is how I am implementing those.

.forRoot is simply a convention to indicate that a module includes service providers. These should only be included a single time in an application. By convention, this is in the root. But it actually doesnt matter. You can provide services in any module, but if a service is provided twice, it will be "newed" twice, which will reset its shared values and likely lead to very confusing behaviour as things that should be there and saved are not.

.forChild is a convention that specifically does not include any providers. It is usually used by routing modules to indicate that they should not be import by the root of the application and pollute the hierarchy.

From a shared module / Lazy loading perspective. I load a few modules with "forRoot" into my shared modules, since that is where I am registering all of my service providers. This seems to work fine, but may not be 100% to style guide. I prefer a clean app.module so, I try to keep things that arent needed in it out of it.

http://blog.angular-university.io/angular2-ngmodule/

relevant link that actually makes some of what I said seem wrong, but, my brain is running on empty. So, check it when you have a gap.

[bogacg]

From a shared module / Lazy loading perspective. I load a few modules with "forRoot" into my shared modules, since that is where I am registering all of my service providers. This seems to work fine, but may not be 100% to style guide. I prefer a clean app.module so, I try to keep things that arent needed in it out of it.

I understand what you are saying. In terms of "if only used by feature/lazy module, add it there", yes, that might be a practice to keep things clean. That's how I do it with another library I use (PrimeNG).
However we might need some modules app level and what I don't understand is when I've added several modules of ng2-bootstrap app/root level, I was expecting them to propagate down the tree, app-wide, lazy loaded modules included. Yet I had to re-add same modules in lazy loaded module definitions for them to work.

Also, to have a clean app.module file, actually it's better to create a Core.Module file, where we include modules that are used root level (and below), but that's to keep things clean, not a technical "must".

[bogacg]

Here is another explanation on this subject:

How to use .forRoot() within feature modules hierarchy

@psamsotha 's answer puts some light on the subject, shares a similar view to yours. I still can't see the need to already in app.module defined shared module (w. .forRoot()) to other modules. If it's in app.module, it should get propagated down to entire app.

[SiasMey]

If its in the app module, it is propogated down the entire app.

Except for lazy loaded modules. Which get their own di context to make sure that whatever module I wrote that you are lazy loading in your app doesnt cause unexpected side effects by registering a UserComponent that is not the same as yours.

[valorkin]

is issue is fixed?

[bogacg]

@valorkin now I think it's more of a "point of view" on how you implement modules rather than an issue. Closing it is fine by me.