From ffdf5caed3141b5e767d1792274e252eaa411477 Mon Sep 17 00:00:00 2001
From: Patrice Chalin <chalin@users.noreply.github.com>
Date: Tue, 7 Mar 2017 10:09:07 -0800
Subject: [PATCH] docs(hier-dep-inj): fix comp name, spelling in field name,
 copyedits (#3335)

* docs(hier-dep-inj): fix in comp name, spelling in field name, copyedits
- `villaines` --> `villains`
- `TaxReturnComponent` --> `HeroTaxReturnComponent`
- Moved `@Input()` to be on setter rather than getter.
- Other misc copyedits
---
 .../ts/src/app/hero-tax-return.component.ts   |  3 ++-
 .../ts/src/app/villains-list.component.html   |  2 +-
 .../ts/src/app/villains-list.component.ts     |  6 ++---
 .../hierarchical-dependency-injection.jade    | 23 +++++++++++--------
 4 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/hero-tax-return.component.ts b/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/hero-tax-return.component.ts
index 78d0f97763..be9fbd0f5a 100644
--- a/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/hero-tax-return.component.ts
+++ b/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/hero-tax-return.component.ts
@@ -15,10 +15,11 @@ import { HeroTaxReturnService } from './hero-tax-return.service';
 export class HeroTaxReturnComponent {
   message = '';
   @Output() close = new EventEmitter<void>();
-  @Input()
+
   get taxReturn(): HeroTaxReturn {
     return this.heroTaxReturnService.taxReturn;
   }
+  @Input()
   set taxReturn (htr: HeroTaxReturn) {
     this.heroTaxReturnService.taxReturn = htr;
   }
diff --git a/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/villains-list.component.html b/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/villains-list.component.html
index 4d1fb55482..75e5ba3237 100644
--- a/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/villains-list.component.html
+++ b/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/villains-list.component.html
@@ -1,6 +1,6 @@
 <div>
   <h3>Villains</h3>
   <ul>
-    <li *ngFor="let villain of villaines | async">{{villain.name}}</li>
+    <li *ngFor="let villain of villains | async">{{villain.name}}</li>
   </ul>
 </div>
diff --git a/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/villains-list.component.ts b/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/villains-list.component.ts
index 105aaca14f..f371c740c0 100644
--- a/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/villains-list.component.ts
+++ b/public/docs/_examples/hierarchical-dependency-injection/ts/src/app/villains-list.component.ts
@@ -13,9 +13,9 @@ import { Villain, VillainsService } from './villains.service';
 })
 // #enddocregion metadata
 export class VillainsListComponent {
-  villaines: Observable<Villain[]>;
+  villains: Observable<Villain[]>;
 
-  constructor(private villainesService: VillainsService) {
-    this.villaines = villainesService.getVillains();
+  constructor(private villainsService: VillainsService) {
+    this.villains = villainsService.getVillains();
   }
 }
diff --git a/public/docs/ts/latest/guide/hierarchical-dependency-injection.jade b/public/docs/ts/latest/guide/hierarchical-dependency-injection.jade
index 1b8a0df730..5a9a692aac 100644
--- a/public/docs/ts/latest/guide/hierarchical-dependency-injection.jade
+++ b/public/docs/ts/latest/guide/hierarchical-dependency-injection.jade
@@ -56,10 +56,11 @@ figure.image-display
   :marked
     You can cap the bubbling. An intermediate component can declare that it is the "host" component.
     The hunt for providers will climb no higher than the injector for that host component.
-    This a topic for another day.
+    This is a topic for another day.
 
 :marked
   ### Re-providing a service at different levels
+
   You can re-register a provider for a particular dependency token at multiple levels of the injector tree.
   You don't *have* to re-register providers. You shouldn't do so unless you have a good reason. 
   But you *can*.
@@ -77,7 +78,6 @@ figure.image-display
 
   The ability to configure one or more providers at different levels opens up interesting and useful possibilities.
 
-:marked
   ### Scenario: service isolation
 
   Architectural reasons may lead you to restrict access to a service to the application domain where it belongs.
@@ -93,9 +93,10 @@ figure.image-display
 
   Instead, provide the `VillainsService` in the `providers` metadata of the `VillainsListComponent` like this:
 
-+makeExample('hierarchical-dependency-injection/ts/src/app/villains-list.component.ts', 'metadata','src/app/villains-list.component.ts (metadata)')(format='.')
++makeExcerpt('src/app/villains-list.component.ts (metadata)')
+
 :marked
-  By providing `VillainsService` in the `VillainsListComponent` metadata &mdash; and nowhere else &mdash;, 
+  By providing `VillainsService` in the `VillainsListComponent` metadata and nowhere else,
   the service becomes available only in the `VillainsListComponent` and its sub-component tree.
   It's still a singleton, but it's a singleton that exist solely in the _villain_ domain.
 
@@ -120,8 +121,9 @@ figure.image-display
 
 figure.image-display
   img(src="/resources/images/devguide/dependency-injection/hid-heroes-anim.gif" width="400" alt="Heroes in action")
+
 :marked
-  One might suppose that the `TaxReturnComponent` has logic to manage and restore changes. 
+  One might suppose that the `HeroTaxReturnComponent` has logic to manage and restore changes. 
   That would be a pretty easy task for a simple hero tax return. 
   In the real world, with a rich tax return data model, the change management would be tricky.
   You might delegate that management to a helper service, as this example does.
@@ -129,11 +131,13 @@ figure.image-display
   Here is the `HeroTaxReturnService`. 
   It caches a single `HeroTaxReturn`, tracks changes to that return, and can save or restore it.
   It also delegates to the application-wide, singleton `HeroService`, which it gets by injection.
-+makeExample('hierarchical-dependency-injection/ts/src/app/hero-tax-return.service.ts', '', 'src/app/hero-tax-return.service.ts')
+
++makeExample('src/app/hero-tax-return.service.ts')
 
 :marked
   Here is the `HeroTaxReturnComponent` that makes use of it.
-+makeExample('hierarchical-dependency-injection/ts/src/app/hero-tax-return.component.ts', null, 'src/app/hero-tax-return.component.ts')
+
++makeExample('src/app/hero-tax-return.component.ts')
 
 :marked
   The _tax-return-to-edit_ arrives via the input property which is implemented with getters and setters.
@@ -148,7 +152,8 @@ figure.image-display
 
   Look closely at the metadata for the `HeroTaxReturnComponent`. Notice the `providers` property.
 
-+makeExample('hierarchical-dependency-injection/ts/src/app/hero-tax-return.component.ts', 'providers')
++makeExcerpt('src/app/hero-tax-return.component.ts', 'providers', '')
+
 :marked
   The `HeroTaxReturnComponent` has its own provider of the `HeroTaxReturnService`. 
   Recall that every component _instance_ has its own injector. 
@@ -194,7 +199,7 @@ figure.image-display
   :marked
     The code for this _cars_ scenario is in the `car.components.ts` and `car.services.ts` files of the sample
     which you can review and download from the <live-example></live-example>
-:marked
+
 //- ## Advanced Dependency Injection in Angular
 //- Restrict Dependency Lookups
 //- [TODO] (@Host) This has been postponed for now until we come up with a decent use case