Shared module imported in AppModule
up vote
0
down vote
favorite
I was reading the Angular documentation about modules, looking for a line that discourages importing a SharedModule inside the AppModule.
I didn't find anything about that, just a GitHub issue which states that it's better not to import it. However without any deep explain...
https://github.com/tomastrajan/angular-ngrx-material-starter/issues/47
Angular discourages providing services in the Shared modules, which indeed I agree. But nothing else.
So my question is:
Since all my feature modules are lazy-loaded, and needs to import the shared module, but also my app component needs to use stuff provided by the same shared module, is it a bad practice to import it into the AppModule?
What may the consequences be?
Thanks in advance to anyone
angular
add a comment |
up vote
0
down vote
favorite
I was reading the Angular documentation about modules, looking for a line that discourages importing a SharedModule inside the AppModule.
I didn't find anything about that, just a GitHub issue which states that it's better not to import it. However without any deep explain...
https://github.com/tomastrajan/angular-ngrx-material-starter/issues/47
Angular discourages providing services in the Shared modules, which indeed I agree. But nothing else.
So my question is:
Since all my feature modules are lazy-loaded, and needs to import the shared module, but also my app component needs to use stuff provided by the same shared module, is it a bad practice to import it into the AppModule?
What may the consequences be?
Thanks in advance to anyone
angular
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I was reading the Angular documentation about modules, looking for a line that discourages importing a SharedModule inside the AppModule.
I didn't find anything about that, just a GitHub issue which states that it's better not to import it. However without any deep explain...
https://github.com/tomastrajan/angular-ngrx-material-starter/issues/47
Angular discourages providing services in the Shared modules, which indeed I agree. But nothing else.
So my question is:
Since all my feature modules are lazy-loaded, and needs to import the shared module, but also my app component needs to use stuff provided by the same shared module, is it a bad practice to import it into the AppModule?
What may the consequences be?
Thanks in advance to anyone
angular
I was reading the Angular documentation about modules, looking for a line that discourages importing a SharedModule inside the AppModule.
I didn't find anything about that, just a GitHub issue which states that it's better not to import it. However without any deep explain...
https://github.com/tomastrajan/angular-ngrx-material-starter/issues/47
Angular discourages providing services in the Shared modules, which indeed I agree. But nothing else.
So my question is:
Since all my feature modules are lazy-loaded, and needs to import the shared module, but also my app component needs to use stuff provided by the same shared module, is it a bad practice to import it into the AppModule?
What may the consequences be?
Thanks in advance to anyone
angular
angular
asked Nov 7 at 9:16
Caius
523825
523825
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
The problem with importing a SharedModule
into the AppModule
is that the providers will be injected twice in the feature modules (once by you, once by the AppModule
).
The common pattern to achieve that is not to expose providers directly on the @NgModule
declaration but in a static forRoot
function (the name is not mandatory, it's a convention) like that:
export class SharedModule {
static forRoot(): ModuleWithProviders {
return {
ngModule: SharedModule,
providers: [
...
]
};
}
}
When importing the SharedModule
into AppModule
, use SharedModule.forRoot()
, when you import it in a feature module just import it as SharedModule
Right! Thanks for the tip! Other than that you don't see any other "problems"? The only thing that worries me is that the SharedModule could grow in time, so will it be a huge monolith when deployed and requested by the user when loading AppModule?
– Caius
Nov 7 at 9:34
1
For me, the only other thing that could happen is indeed the shared module to become very big, and cause every JS chunk (initial or lazy loaded) to become big too, with potentially unused code (even though the tree shaking looks quite efficient). But I think it's a problem that you'll have time to see coming, if it happens.
– YoukouleleY
Nov 7 at 9:40
1
Again, thank you. <3
– Caius
Nov 7 at 9:46
add a comment |
up vote
1
down vote
Just have a look in this link shared module its not a bad practice to import your shared module in AppModule
Shared module is all about having common modules like if you have form module
some module
which is needed on all your modules instead of importing in all modules you can import it in shared module
and export the same - check the link for further clarification
For service it can be injected just in one module the AppModule
- Services are injectable
and can be used in any module if it has been injected in root module
@Injectable({
providedIn: 'root'
})
Use this decorator in your service top it will automatically inject your service in root module
Thanks - Happy coding !!
Marking the answer below as accepted since it pointed out an important step, other than that, even yours is a valid one, so I up voted it. Thank you for your time :)
– Caius
Nov 7 at 9:35
No issues - Thanks
– Rahul Swamynathan
Nov 7 at 9:47
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
The problem with importing a SharedModule
into the AppModule
is that the providers will be injected twice in the feature modules (once by you, once by the AppModule
).
The common pattern to achieve that is not to expose providers directly on the @NgModule
declaration but in a static forRoot
function (the name is not mandatory, it's a convention) like that:
export class SharedModule {
static forRoot(): ModuleWithProviders {
return {
ngModule: SharedModule,
providers: [
...
]
};
}
}
When importing the SharedModule
into AppModule
, use SharedModule.forRoot()
, when you import it in a feature module just import it as SharedModule
Right! Thanks for the tip! Other than that you don't see any other "problems"? The only thing that worries me is that the SharedModule could grow in time, so will it be a huge monolith when deployed and requested by the user when loading AppModule?
– Caius
Nov 7 at 9:34
1
For me, the only other thing that could happen is indeed the shared module to become very big, and cause every JS chunk (initial or lazy loaded) to become big too, with potentially unused code (even though the tree shaking looks quite efficient). But I think it's a problem that you'll have time to see coming, if it happens.
– YoukouleleY
Nov 7 at 9:40
1
Again, thank you. <3
– Caius
Nov 7 at 9:46
add a comment |
up vote
1
down vote
accepted
The problem with importing a SharedModule
into the AppModule
is that the providers will be injected twice in the feature modules (once by you, once by the AppModule
).
The common pattern to achieve that is not to expose providers directly on the @NgModule
declaration but in a static forRoot
function (the name is not mandatory, it's a convention) like that:
export class SharedModule {
static forRoot(): ModuleWithProviders {
return {
ngModule: SharedModule,
providers: [
...
]
};
}
}
When importing the SharedModule
into AppModule
, use SharedModule.forRoot()
, when you import it in a feature module just import it as SharedModule
Right! Thanks for the tip! Other than that you don't see any other "problems"? The only thing that worries me is that the SharedModule could grow in time, so will it be a huge monolith when deployed and requested by the user when loading AppModule?
– Caius
Nov 7 at 9:34
1
For me, the only other thing that could happen is indeed the shared module to become very big, and cause every JS chunk (initial or lazy loaded) to become big too, with potentially unused code (even though the tree shaking looks quite efficient). But I think it's a problem that you'll have time to see coming, if it happens.
– YoukouleleY
Nov 7 at 9:40
1
Again, thank you. <3
– Caius
Nov 7 at 9:46
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
The problem with importing a SharedModule
into the AppModule
is that the providers will be injected twice in the feature modules (once by you, once by the AppModule
).
The common pattern to achieve that is not to expose providers directly on the @NgModule
declaration but in a static forRoot
function (the name is not mandatory, it's a convention) like that:
export class SharedModule {
static forRoot(): ModuleWithProviders {
return {
ngModule: SharedModule,
providers: [
...
]
};
}
}
When importing the SharedModule
into AppModule
, use SharedModule.forRoot()
, when you import it in a feature module just import it as SharedModule
The problem with importing a SharedModule
into the AppModule
is that the providers will be injected twice in the feature modules (once by you, once by the AppModule
).
The common pattern to achieve that is not to expose providers directly on the @NgModule
declaration but in a static forRoot
function (the name is not mandatory, it's a convention) like that:
export class SharedModule {
static forRoot(): ModuleWithProviders {
return {
ngModule: SharedModule,
providers: [
...
]
};
}
}
When importing the SharedModule
into AppModule
, use SharedModule.forRoot()
, when you import it in a feature module just import it as SharedModule
answered Nov 7 at 9:21
YoukouleleY
1,9921721
1,9921721
Right! Thanks for the tip! Other than that you don't see any other "problems"? The only thing that worries me is that the SharedModule could grow in time, so will it be a huge monolith when deployed and requested by the user when loading AppModule?
– Caius
Nov 7 at 9:34
1
For me, the only other thing that could happen is indeed the shared module to become very big, and cause every JS chunk (initial or lazy loaded) to become big too, with potentially unused code (even though the tree shaking looks quite efficient). But I think it's a problem that you'll have time to see coming, if it happens.
– YoukouleleY
Nov 7 at 9:40
1
Again, thank you. <3
– Caius
Nov 7 at 9:46
add a comment |
Right! Thanks for the tip! Other than that you don't see any other "problems"? The only thing that worries me is that the SharedModule could grow in time, so will it be a huge monolith when deployed and requested by the user when loading AppModule?
– Caius
Nov 7 at 9:34
1
For me, the only other thing that could happen is indeed the shared module to become very big, and cause every JS chunk (initial or lazy loaded) to become big too, with potentially unused code (even though the tree shaking looks quite efficient). But I think it's a problem that you'll have time to see coming, if it happens.
– YoukouleleY
Nov 7 at 9:40
1
Again, thank you. <3
– Caius
Nov 7 at 9:46
Right! Thanks for the tip! Other than that you don't see any other "problems"? The only thing that worries me is that the SharedModule could grow in time, so will it be a huge monolith when deployed and requested by the user when loading AppModule?
– Caius
Nov 7 at 9:34
Right! Thanks for the tip! Other than that you don't see any other "problems"? The only thing that worries me is that the SharedModule could grow in time, so will it be a huge monolith when deployed and requested by the user when loading AppModule?
– Caius
Nov 7 at 9:34
1
1
For me, the only other thing that could happen is indeed the shared module to become very big, and cause every JS chunk (initial or lazy loaded) to become big too, with potentially unused code (even though the tree shaking looks quite efficient). But I think it's a problem that you'll have time to see coming, if it happens.
– YoukouleleY
Nov 7 at 9:40
For me, the only other thing that could happen is indeed the shared module to become very big, and cause every JS chunk (initial or lazy loaded) to become big too, with potentially unused code (even though the tree shaking looks quite efficient). But I think it's a problem that you'll have time to see coming, if it happens.
– YoukouleleY
Nov 7 at 9:40
1
1
Again, thank you. <3
– Caius
Nov 7 at 9:46
Again, thank you. <3
– Caius
Nov 7 at 9:46
add a comment |
up vote
1
down vote
Just have a look in this link shared module its not a bad practice to import your shared module in AppModule
Shared module is all about having common modules like if you have form module
some module
which is needed on all your modules instead of importing in all modules you can import it in shared module
and export the same - check the link for further clarification
For service it can be injected just in one module the AppModule
- Services are injectable
and can be used in any module if it has been injected in root module
@Injectable({
providedIn: 'root'
})
Use this decorator in your service top it will automatically inject your service in root module
Thanks - Happy coding !!
Marking the answer below as accepted since it pointed out an important step, other than that, even yours is a valid one, so I up voted it. Thank you for your time :)
– Caius
Nov 7 at 9:35
No issues - Thanks
– Rahul Swamynathan
Nov 7 at 9:47
add a comment |
up vote
1
down vote
Just have a look in this link shared module its not a bad practice to import your shared module in AppModule
Shared module is all about having common modules like if you have form module
some module
which is needed on all your modules instead of importing in all modules you can import it in shared module
and export the same - check the link for further clarification
For service it can be injected just in one module the AppModule
- Services are injectable
and can be used in any module if it has been injected in root module
@Injectable({
providedIn: 'root'
})
Use this decorator in your service top it will automatically inject your service in root module
Thanks - Happy coding !!
Marking the answer below as accepted since it pointed out an important step, other than that, even yours is a valid one, so I up voted it. Thank you for your time :)
– Caius
Nov 7 at 9:35
No issues - Thanks
– Rahul Swamynathan
Nov 7 at 9:47
add a comment |
up vote
1
down vote
up vote
1
down vote
Just have a look in this link shared module its not a bad practice to import your shared module in AppModule
Shared module is all about having common modules like if you have form module
some module
which is needed on all your modules instead of importing in all modules you can import it in shared module
and export the same - check the link for further clarification
For service it can be injected just in one module the AppModule
- Services are injectable
and can be used in any module if it has been injected in root module
@Injectable({
providedIn: 'root'
})
Use this decorator in your service top it will automatically inject your service in root module
Thanks - Happy coding !!
Just have a look in this link shared module its not a bad practice to import your shared module in AppModule
Shared module is all about having common modules like if you have form module
some module
which is needed on all your modules instead of importing in all modules you can import it in shared module
and export the same - check the link for further clarification
For service it can be injected just in one module the AppModule
- Services are injectable
and can be used in any module if it has been injected in root module
@Injectable({
providedIn: 'root'
})
Use this decorator in your service top it will automatically inject your service in root module
Thanks - Happy coding !!
answered Nov 7 at 9:24
Rahul Swamynathan
710112
710112
Marking the answer below as accepted since it pointed out an important step, other than that, even yours is a valid one, so I up voted it. Thank you for your time :)
– Caius
Nov 7 at 9:35
No issues - Thanks
– Rahul Swamynathan
Nov 7 at 9:47
add a comment |
Marking the answer below as accepted since it pointed out an important step, other than that, even yours is a valid one, so I up voted it. Thank you for your time :)
– Caius
Nov 7 at 9:35
No issues - Thanks
– Rahul Swamynathan
Nov 7 at 9:47
Marking the answer below as accepted since it pointed out an important step, other than that, even yours is a valid one, so I up voted it. Thank you for your time :)
– Caius
Nov 7 at 9:35
Marking the answer below as accepted since it pointed out an important step, other than that, even yours is a valid one, so I up voted it. Thank you for your time :)
– Caius
Nov 7 at 9:35
No issues - Thanks
– Rahul Swamynathan
Nov 7 at 9:47
No issues - Thanks
– Rahul Swamynathan
Nov 7 at 9:47
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53186466%2fshared-module-imported-in-appmodule%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown