docs(guide/hierarchical-injectors): fix typo
This commit is contained in:
parent
ff5f21fc74
commit
615a8d4147
|
@ -9,9 +9,9 @@ include ../../../../_includes/_util-fns
|
|||
that parallel an application's component tree.
|
||||
We can re-configure the injectors at any level of that component tree with
|
||||
interesting and useful results.
|
||||
|
||||
|
||||
In this chapter we explore these points and write some code.
|
||||
|
||||
|
||||
[Live Example](/resources/live-examples/hierarchical-dependency-injection/ts/plnkr.html).
|
||||
|
||||
.l-main-section
|
||||
|
@ -21,19 +21,19 @@ include ../../../../_includes/_util-fns
|
|||
In the [Dependency Injection](./dependency-injection.html) chapter
|
||||
we learned how to configure a dependency injector and how to retrieve dependencies where we need them.
|
||||
|
||||
We oversimplified. In fact, there is no such thing as ***the*** injector!
|
||||
We oversimplified. In fact, there is no such thing as ***the*** injector!
|
||||
An application may have multiple injectors!
|
||||
|
||||
An Angular application is a tree of components. Each component instance has its own injector!
|
||||
The tree of components parallels the tree of injectors.
|
||||
|
||||
|
||||
|
||||
.l-sub-section
|
||||
:marked
|
||||
Angular doesn't *literally* create a separate injector for each component.
|
||||
Every component doesn't need its own injector and it would be horribly inefficient to create
|
||||
Angular doesn't *literally* create a separate injector for each component.
|
||||
Every component doesn't need its own injector and it would be horribly inefficient to create
|
||||
masses of injectors for no good purpose.
|
||||
|
||||
|
||||
But it is true that every component ***has an injector*** (even if it shares that injector with another component)
|
||||
and there may be many different injector instances operating at different levels of the component tree.
|
||||
|
||||
|
@ -135,12 +135,12 @@ figure.image-display
|
|||
|
||||
Our `HeroEditComponent` uses this services under the hood for it’s `hero` property. It intercepts the `get` and `set` method to delegate the actual work to our `RestoreService` which in turn makes sure that we won’t work on the original item but on a copy instead.
|
||||
|
||||
At this point we may be scratching our heads asking what this has to do with component injectors?
|
||||
If closely at the metadata for our `HeroEditComponent`. Notice the `providers` property.
|
||||
At this point we may be scratching our heads asking what this has to do with component injectors?
|
||||
Look closely at the metadata for our `HeroEditComponent`. Notice the `providers` property.
|
||||
|
||||
+makeExample('hierarchical-dependency-injection/ts/app/hero-editor.component.ts', 'providers')
|
||||
:marked
|
||||
This adds a `RestoreService` provider to the injector of the `HeroEditComponent`.
|
||||
This adds a `RestoreService` provider to the injector of the `HeroEditComponent`.
|
||||
Couldn’t we simply alter our bootstrap call to this?
|
||||
|
||||
+makeExample('hierarchical-dependency-injection/ts/app/boot.ts', 'bad-alternative')
|
||||
|
@ -155,11 +155,11 @@ figure.image-display
|
|||
Any of those injectors could have its own instance of the service.
|
||||
|
||||
If we defined a `RestoreService` provider only on the root component,
|
||||
we would have exactly one instance of that service and it would be shared across the entire application.
|
||||
|
||||
we would have exactly one instance of that service and it would be shared across the entire application.
|
||||
|
||||
That’s clearly not what we want in this scenario. We want each component to have its own instance of the `RestoreService`.
|
||||
Defining (or re-defining) a provider at the component level creates a new instance of the service for each new instance
|
||||
of that component. We've made the `RestoreService` a kind of "private" singleton for each `HeroEditComponent`,
|
||||
of that component. We've made the `RestoreService` a kind of "private" singleton for each `HeroEditComponent`,
|
||||
scoped to that component instance and its child components.
|
||||
|
||||
<!--
|
||||
|
|
Loading…
Reference in New Issue