docs(guide/hierarchical-injectors): fix typo

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.
 
   <!--