iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: clarify faqs about services (#24079) 

PR Close #24079
This commit is contained in:
Kapunahele Wong 2018-05-23 14:51:05 -04:00 committed by Miško Hevery
parent 56a8533cf3
commit b719905f9b
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
aio/content/guide/ngmodule-faq.md
View File

@ -219,7 +219,7 @@ configure services in root and feature modules respectively.
Angular doesn't recognize these names but Angular developers do.
Follow this convention when you write similar modules with configurable service providers.
<!--KW--I don't understand how Angular doesn't understand these methods...-->
<hr/>
@ -233,9 +233,8 @@ When you import an NgModule,
Angular adds the module's service providers (the contents of its `providers` list)
to the application root injector.
This makes the provider visible to every class in the application that knows the provider's lookup token, or knows its name.
This makes the provider visible to every class in the application that knows the provider's lookup token, or name.
This is by design.
Extensibility through NgModule imports is a primary goal of the NgModule system.
Merging NgModule providers into the application injector
makes it easy for a module library to enrich the entire application with new services.
@ -247,6 +246,8 @@ If the `HeroModule` provides the `HeroService` and the root `AppModule` imports
any class that knows the `HeroService` _type_ can inject that service,
not just the classes declared in the `HeroModule`.
To limit access to a service, consider lazy loading the NgModule that provides that service. See [How do I restrict service scope to a module?](guide/ngmodule-faq#service-scope) for more information.
<hr/>
{@a q-lazy-loaded-module-provider-visibility}
@ -288,6 +289,7 @@ The `AppModule` always wins.
<hr/>
{@a service-scope}
## How do I restrict service scope to a module?
@ -335,6 +337,8 @@ You can embed the child components in the top component's template.
Alternatively, make the top component a routing host by giving it a `<router-outlet>`.
Define child routes and let the router load module components into that outlet.
Though you can limit access to a service by providing it in a lazy loaded module or providing it in a component, providing services in a component can lead to multiple instances of those services. Thus, the lazy loading is preferable.
<hr/>
{@a q-root-component-or-module}