diff --git a/public/docs/ts/latest/guide/hierarchical-dependency-injection.jade b/public/docs/ts/latest/guide/hierarchical-dependency-injection.jade index 82133e09c9..b06183be6e 100644 --- a/public/docs/ts/latest/guide/hierarchical-dependency-injection.jade +++ b/public/docs/ts/latest/guide/hierarchical-dependency-injection.jade @@ -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.