anchor.diff:    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
  
positive.code: 
    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.
  
  +makeExample('hierarchical-dependency-injection/ts/app/hero-editor.component.ts', 'providers')
  :marked
    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')
  
negative.code:   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.
  
    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`,
    scoped to that component instance and its child components.
  
    <!--
  