`.
+ Then we add the `ngIf` built-in directive and set it to the `selectedHero` property of our component.
+
+ +makeExample('toh-2/dart-snippets/app_component_snippets_pt2.dart', 'ng-if', 'app_component.dart (ngIf)')
+
+ .alert.is-critical
+ :marked
+ Remember that the leading asterisk (`*`) in front of `ngIf` is
+ a critical part of this syntax.
+ :marked
+ When there is no `selectedHero`, the `ngIf` directive removes the hero detail HTML from the DOM.
+ There will be no hero detail elements and no bindings to worry about.
+
+ When the user picks a hero, `selectedHero` isn't `null` anymore and
+ `ngIf` puts the hero detail content into the DOM and evaluates the nested bindings.
+ .l-sub-section
+ :marked
+ `ngIf` and `ngFor` are called “structural directives” because they can change the
+ structure of portions of the DOM.
+ In other words, they give structure to the way Angular displays content in the DOM.
+
+ Learn more about `ngIf`, `ngFor` and other structural directives in the
+ [Structural Directives](../guide/structural-directives.html) and
+ [Template Syntax](../guide/template-syntax.html#directives) chapters.
+
+ :marked
+ The browser refreshes and we see the list of heroes but not the selected hero detail.
+ The `ngIf` keeps it out of the DOM as long as the `selectedHero` is undefined.
+ When we click on a hero in the list, the selected hero displays in the hero details.
+ Everything is working as we expect.
+
+ ### Styling the selection
+
+ We see the selected hero in the details area below but we can’t quickly locate that hero in the list above.
+ We can fix that by applying the `selected` CSS class to the appropriate `
` in the master list.
+ For example, when we select Magneta from the heroes list,
+ we can make it pop out visually by giving it a subtle background color as shown here.
+
+ figure.image-display
+ img(src='/resources/images/devguide/toh/heroes-list-selected.png' alt="Selected hero")
+ :marked
+ We’ll add a property binding on `class` for the `selected` class to the template. We'll set this to an expression that compares the current `selectedHero` to the `hero`.
+
+ The key is the name of the CSS class (`selected`). The value is `true` if the two heroes match and `false` otherwise.
+ We’re saying “*apply the `selected` class if the heroes match, remove it if they don’t*”.
+ +makeExample('toh-2/dart-snippets/app_component_snippets_pt2.dart', 'class-selected-1', 'app_component.dart (Setting the CSS class)')(format=".")
+ :marked
+ Notice in the template that the `class.selected` is surrounded in square brackets (`[]`).
+ This is the syntax for a Property Binding, a binding in which data flows one way
+ from the data source (the expression `hero == selectedHero`) to a property of `class`.
+ +makeExample('toh-2/dart-snippets/app_component_snippets_pt2.dart', 'class-selected-2', 'app_component.dart (Styling each hero)')(format=".")
+
+ .l-sub-section
+ :marked
+ Learn more about [Property Binding](../guide/template-syntax.html#property-binding)
+ in the Template Syntax chapter.
+
+ :marked
+ The browser reloads our app.
+ We select the hero Magneta and the selection is clearly identified by the background color.
+
+ figure.image-display
+ img(src='/resources/images/devguide/toh/heroes-list-1.png' alt="Output of heroes list app")
+
+ :marked
+ We select a different hero and the tell-tale color switches to that hero.
+
+ Here's the complete `app_component.dart` as it stands now:
+
+ +makeExample('toh-2/dart/lib/app_component.dart', 'pt2', 'app_component.dart')
+
+.l-main-section
+:marked
+ ## The Road We’ve Travelled
+ Here’s what we achieved in this chapter:
+
+ * Our Tour of Heroes now displays a list of selectable heroes
+ * We added the ability to select a hero and show the hero’s details
+ * We learned how to use the built-in directives `ngIf` and `ngFor` in a component’s template
+
+ [Run the live example for part 2](https://tour-of-heroes.firebaseapp.com/toh2/)
+
+ ### The Road Ahead
+ Our Tour of Heroes has grown, but it’s far from complete.
+ We can't put the entire app into a single component.
+ We need to break it up into sub-components and teach them to work together
+ as we learn in the [next chapter](toh-pt3.html).
diff --git a/public/docs/dart/latest/tutorial/toh-pt3.jade b/public/docs/dart/latest/tutorial/toh-pt3.jade
new file mode 100644
index 0000000000..83fe25cf81
--- /dev/null
+++ b/public/docs/dart/latest/tutorial/toh-pt3.jade
@@ -0,0 +1,252 @@
+include ../../../../_includes/_util-fns
+
+:marked
+ Our app is growing.
+ Use cases are flowing in for reusing components, passing data to components, and creating more reusable assets. Let's separate the heroes list from the hero details and make the details component reusable.
+
+ [Run the live example for part 3](https://tour-of-heroes.firebaseapp.com/toh3/)
+
+.l-main-section
+:marked
+ ## Where We Left Off
+ Before we continue with our Tour of Heroes, let’s verify we have the following structure. If not, we’ll need to go back and follow the previous chapters.
+
+.filetree
+ .file angular2_tour_of_heroes
+ .children
+ .file lib
+ .children
+ .file app_component.dart
+ .file web
+ .children
+ .file index.html
+ .file main.dart
+ .file pubspec.yaml
+:marked
+ ### Keep the app transpiling and running
+ We want to start the Dart compiler, have it watch for changes, and start our server. We'll do this by typing
+
+code-example(format="." language="bash").
+ pub serve
+
+:marked
+ This will keep the application running while we continue to build the Tour of Heroes.
+
+ ## Making a Hero Detail Component
+ Our heroes list and our hero details are in the same component in the same file.
+ They're small now but each could grow.
+ We are sure to receive new requirements for one and not the other.
+ Yet every change puts both components at risk and doubles the testing burden without benefit.
+ If we had to reuse the hero details elsewhere in our app,
+ the heroes list would tag along for the ride.
+
+ Our current component violates the
+ [Single Responsibility Principle](https://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html).
+ It's only a tutorial but we can still do things right —
+ especially if doing them right is easy and we learn how to build Angular apps in the process.
+
+ Let’s break the hero details out into its own component.
+
+ ### Separating the Hero Detail Component
+ Add a new file named `hero_detail_component.dart` to the `lib` folder and create `HeroDetailComponent` as follows.
+
++makeExample('toh-3/dart/lib/hero_detail_component.dart', 'v1', 'hero_detail_component.dart (initial version)')(format=".")
+.l-sub-section
+ :marked
+ ### Naming conventions
+ We like to identify at a glance which classes are components and which files contain components.
+
+ Notice that we have an `AppComponent` in a file named `app_component.dart` and our new
+ `HeroDetailComponent` is in a file named `hero_detail_component.dart`.
+
+ All of our component names end in "Component". All of our component file names end in "_component".
+
+ We spell our file names in lower dash case (AKA "kebab case") so we don't worry about
+ case sensitivity on the server or in source control.
+
+
+:marked
+ We begin by importing the `Component` function from Angular so that we have it handy when we create
+ the metadata for our component.
+
+ We create metadata with the `@Component` decorator where we
+ specify the selector name that identifies this component's element.
+
+ When we finish here, we'll import it into `AppComponent` and refer to its `` element.
+:marked
+ #### Hero Detail Template
+ At the moment, the *Heroes* and *Hero Detail* views are combined in one template in `AppComponent`.
+ Let’s **cut** the *Hero Detail* content from `AppComponent` and **paste** it into the new template property of `HeroDetailComponent`.
+
+ We previously bound to the `selectedHero.name` property of the `AppComponent`.
+ Our `HeroDetailComponent` will have a `hero` property, not a `selectedHero` property.
+ So we replace `selectedHero` with `hero` everywhere in our new template. That's our only change.
+ The result looks like this:
+
++makeExample('toh-3/dart/lib/hero_detail_component.dart', 'template', 'hero_detail_component.dart (template)')(format=".")
+
+:marked
+ Now our hero detail layout exists only in the `HeroDetailComponent`.
+
+ #### Add the *hero* property
+ Let’s add that `hero` property we were talking about to the component class.
++makeExample('toh-3/dart/lib/hero_detail_component.dart', 'hero')
+:marked
+ Uh oh. We declared the `hero` property as type `Hero` but our `Hero` class is over in the `app_component.dart` file.
+ We have two components, each in their own file, that need to reference the `Hero` class.
+
+ We solve the problem by relocating the `Hero` class from `app_component.dart` to its own `hero.dart` file.
+
++makeExample('toh-3/dart/lib/hero.dart', null, 'hero.dart (Exported Hero class)')(format=".")
+
+:marked
+ Add the following import statement near the top of both `app_component.dart` and `hero_detail_component.dart`.
+
++makeExample('toh-3/dart/lib/hero_detail_component.dart', 'hero-import', 'hero_detail_component.dart and app_component.dart (Import the Hero class)')
+
+:marked
+ #### The *hero* property is an ***input***
+
+ The `HeroDetailComponent` must be told what hero to display. Who will tell it? The parent `AppComponent`!
+
+ The `AppComponent` knows which hero to show: the hero that the user selected from the list.
+ The user's selection is in its `selectedHero` property.
+
+ We will soon update the `AppComponent` template so that it binds its `selectedHero` property
+ to the `hero` property of our `HeroDetailComponent`. The binding *might* look like this:
+code-example(format=".").
+ <my-hero-detail [hero]="selectedHero"></my-hero-detail>
+:marked
+ Notice that the `hero` property is the ***target*** of a property binding — it's in square brackets to the left of the (=).
+
+ Angular insists that we declare a ***target*** property to be an ***input*** property.
+ If we don't, Angular rejects the binding and throws an error.
+.l-sub-section
+ :marked
+ We explain input properties in more detail [here](../guide/attribute-directives.html#why-input)
+ where we also explain why *target* properties require this special treament and
+ *source* properties do not.
+:marked
+ There are a couple of ways we can declare that `hero` is an *input*.
+ We'll do it by adding an `inputs` array to the `@Component` metadata.
++makeExample('toh-3/dart/lib/hero_detail_component.dart', 'inputs')
+
+.l-sub-section
+ :marked
+ Learn about the `@Input()` decorator way in the
+ [Attribute Directives](../guide/attribute-directives.html#input) chapter.
+:marked
+
+.l-main-section
+:marked
+ ## Refresh the AppComponent
+ We return to the `AppComponent` and teach it to use the `HeroDetailComponent`.
+
+ We begin by importing the `HeroDetailComponent` so we can refer to it.
+
++makeExample('toh-3/dart/lib/app_component.dart', 'hero-detail-import')
+
+:marked
+ Find the location in the template where we removed the *Hero Detail* content
+ and add an element tag that represents the `HeroDetailComponent`.
+code-example(format=".").
+ <my-hero-detail></my-hero-detail>
+.l-sub-section
+ :marked
+ *my-hero-detail* is the name we set as the `selector` in the `HeroDetailComponent` metadata.
+:marked
+ The two components won't coordinate until we bind the `selectedHero` property of the `AppComponent`
+ to the `HeroDetailComponent` element's `hero` property like this:
+code-example(format=".")
+ <my-hero-detail [hero]="selectedHero"></my-hero-detail>
+:marked
+ The `AppComponent`’s template should now look like this
+
++makeExample('toh-3/dart/lib/app_component.dart', 'hero-detail-template', 'app_component.dart (Template)')
+:marked
+ Thanks to the binding, the `HeroDetailComponent` should receive the hero from the `AppComponent` and display that hero's detail beneath the list.
+ The detail should update every time the user picks a new hero.
+
+ It's not happening yet!
+
+ We click among the heroes. No details. We look for an error in the console of the browser development tools. No error.
+
+ It is as if Angular were ignoring the new tag. That's because *it is ignoring the new tag*.
+
+ ### The *directives* array
+ A browser ignores HTML tags and attributes that it doesn't recognize. So does Angular.
+
+ We've imported `HeroDetailComponent`, we've used it in the template, but we haven't told Angular about it.
+
+ We tell Angular about it by listing it in the metadata `directives` array. Let's add that array property to the bottom of the
+ `@Component` configuration object, immediately after the `template` and `styles` properties.
++makeExample('toh-3/dart/lib/app_component.dart', 'directives')
+
+
+:marked
+ ### It works!
+ When we view our app in the browser we see the list of heroes.
+ When we select a hero we can see the selected hero’s details.
+
+ What's fundamentally new is that we can use this `HeroDetailComponent`
+ to show hero details anywhere in the app.
+
+ We’ve created our first reusable component!
+
+ ### Reviewing the App Structure
+ Let’s verify that we have the following structure after all of our good refactoring in this chapter:
+
+.filetree
+ .file angular2_tour_of_heroes
+ .children
+ .file lib
+ .children
+ .file app_component.dart
+ .file hero.dart
+ .file hero_detail_component.dart
+ .file web
+ .children
+ .file index.html
+ .file main.dart
+ .file pubspec.yaml
+:marked
+ Here are the code files we discussed in this chapter.
+
++makeTabs(`
+ toh-3/dart/lib/hero_detail_component.dart,
+ toh-3/dart/lib/app_component.dart,
+ toh-3/dart/lib/hero.dart
+ `,'',`
+ lib/hero_detail_component.dart,
+ lib/app_component.dart,
+ lib/hero.dart
+ `)
+
+.l-main-section
+:marked
+ ## The Road We’ve Travelled
+ Let’s take stock of what we’ve built.
+
+ * We created a reusable component
+ * We learned how to make a component accept input
+ * We learned to bind a parent component to a child component.
+ * We learned to declare the application directives we need in a `directives` array.
+
+ [Run the live example for part 3](https://tour-of-heroes.firebaseapp.com/toh3/)
+
+.l-main-section
+:marked
+ ## The Road Ahead
+ Our Tour of Heroes has become more reusable with shared components.
+
+ We're still getting our (mock) data within the `AppComponent`.
+ That's not sustainable.
+ We should refactor data access to a separate service
+ and share it among the components that need data.
+
+ We’ll learn to create services in the [next tutorial](toh-pt4.html) chapter.
diff --git a/public/docs/dart/latest/tutorial/toh-pt4.jade b/public/docs/dart/latest/tutorial/toh-pt4.jade
new file mode 100644
index 0000000000..92a64d4697
--- /dev/null
+++ b/public/docs/dart/latest/tutorial/toh-pt4.jade
@@ -0,0 +1,386 @@
+include ../../../../_includes/_util-fns
+
+:marked
+ # Services
+ The Tour of Heroes is evolving and we anticipate adding more components in the near future.
+
+ Multiple components will need access to hero data and we don't want to copy and
+ paste the same code over and over.
+ Instead, we'll create a single reusable data service and learn to
+ inject it in the components that need it.
+
+ Refactoring data access to a separate service keeps the component lean and focused on supporting the view.
+ It also makes it easier to unit test the component with a mock service.
+
+ Because data services are invariably asynchronous,
+ we'll finish the chapter with a promise-based version of the data service.
+
+ [Run the live example for part 4](https://tour-of-heroes.firebaseapp.com/toh4/)
+
+.l-main-section
+:marked
+ ## Where We Left Off
+ Before we continue with our Tour of Heroes, let’s verify we have the following structure.
+ If not, we’ll need to go back and follow the previous chapters.
+
+.filetree
+ .file angular2_tour_of_heroes
+ .children
+ .file lib
+ .children
+ .file app_component.dart
+ .file hero.dart
+ .file hero_detail_component.dart
+ .file web
+ .children
+ .file index.html
+ .file main.dart
+ .file pubspec.yaml
+:marked
+ ### Keep the app transpiling and running
+ Open a terminal/console window.
+ Start the Dart compiler, watch for changes, and start our server by entering the command:
+
+code-example(format="." language="bash").
+ pub serve
+
+:marked
+ The application runs and updates automatically as we continue to build the Tour of Heroes.
+
+ ## Creating a Hero Service
+ Our stakeholders have shared their larger vision for our app.
+ They tell us they want to show the heroes in various ways on different pages.
+ We already can select a hero from a list.
+ Soon we'll add a dashboard with the top performing heroes and create a separate view for editing hero details.
+ All three views need hero data.
+
+ At the moment the `AppComponent` defines mock heroes for display.
+ We have at least two objections.
+ First, defining heroes is not the component's job.
+ Second, we can't easily share that list of heroes with other components and views.
+
+ We can refactor this hero data acquisition business to a single service that provides heroes and
+ share that service with all components that need heroes.
+
+ ### Create the HeroService
+ Create a file in the `lib` folder called `hero_service.dart`.
+.l-sub-section
+ :marked
+ We've adopted a convention in which we spell the name of a service in lowercase followed by `_service`.
+ If the service name were multi-word, we'd spell the base filename with lower underscore case.
+ The `SpecialSuperHeroService` would be defined in the `special_super_hero_service.dart` file.
+:marked
+ We name the class `HeroService`.
+
++makeExample('toh-4/dart/lib/hero_service_1.dart', 'empty-class', 'hero_service.dart (class)')(format=".")
+
+:marked
+ ### Injectable Services
+ Notice that we imported the Angular `Injectable` function and applied that function as an `@Injectable()` decorator.
+.callout.is-helpful
+ :marked
+ **Don't forget the parentheses!** Neglecting them leads to an error that's difficult to diagnose.
+:marked
+ TypeScript sees the `@Injectable()` decorator and emits metadata about our service,
+ metadata that Angular may need to inject other dependencies into this service.
+
+ The `HeroService` doesn't have any dependencies *at the moment*. Add the decorator anyway.
+ It is a "best practice" to apply the `@Injectable()` decorator *from the start*
+ both for consistency and for future-proofing.
+
+:marked
+ ### Getting Heroes
+ Add a `getHeroes` method stub.
++makeExample('toh-4/dart/lib/hero_service_1.dart', 'getHeroes-stub', 'hero_service.dart ( getHeroes stub)')(format=".")
+:marked
+ We're holding back on the implementation for a moment to make an important point.
+
+ The consumer of our service doesn't know how the service gets the data.
+ Our `HeroService` could get `Hero` data from anywhere.
+ It could get the data from a web service or local storage
+ or from a mock data source.
+
+ That's the beauty of removing data access from the component.
+ We can change our minds about the implementation as often as we like,
+ for whatever reason, without touching any of the components that need heroes.
+
+
+ ### Mock Heroes
+ We already have mock `Hero` data sitting in the `AppComponent`. It doesn't belong there. It doesn't belong *here* either.
+ We'll move the mock data to its own file.
+
+ Cut the the `mockHeroes` list from `app_component.dart` and paste it to a new file in the `lib` folder named `mock_heroes.dart`.
+ We copy the `import 'hero.dart'` statement as well because the heroes list uses the `Hero` class.
+
++makeExample('toh-4/dart/lib/mock_heroes.dart', null, 'mock_heroes.dart (Heroes array)')
+:marked
+ Meanwhile, back in `app_component.dart` where we cut away the `mockHeroes` list,
+ we leave behind an uninitialized `heroes` property:
++makeExample('toh-4/dart/lib/app_component_1.dart', 'heroes-prop', 'app_component.dart (heroes property)')(format=".")
+:marked
+ ### Return Mocked Heroes
+ Back in the `HeroService` we import the mock `mockHeroes` and return it from the `getHeroes` method.
+ Our `HeroService` looks like this:
++makeExample('toh-4/dart/lib/hero_service_1.dart', null, 'hero_service.dart')(format=".")
+:marked
+ ### Use the Hero Service
+ We're ready to use the `HeroService` in other components starting with our `AppComponent`.
+
+ We begin, as usual, by importing the thing we want to use, the `HeroService`.
++makeExample('toh-4/dart/lib/app_component.dart', 'hero-service-import', 'app_component.dart (import HeroService)')
+:marked
+ Importing the service allows us to *reference* it in our code.
+ How should the `AppComponent` acquire a runtime concrete `HeroService` instance?
+
+ ### Do we *new* the *HeroService*? No way!
+ We could create a new instance of the `HeroService` with "new" like this:
++makeExample('toh-4/dart/lib/app_component_1.dart', 'new-service')(format=".")
+:marked
+ That's a bad idea for several reasons including
+
+ * Our component has to know how to create a `HeroService`.
+ If we ever change the `HeroService` constructor,
+ we'll have to find every place we create the service and fix it.
+ Running around patching code is error prone and adds to the test burden.
+
+ * We create a new service each time we use "new".
+ What if the service should cache heroes and share that cache with others?
+ We couldn't do that.
+
+ * We're locking the `AppComponent` into a specific implementation of the `HeroService`.
+ It will be hard to switch implementations for different scenarios.
+ Can we operate offline?
+ Will we need different mocked versions under test?
+ Not easy.
+
+ *What if ... what if ... Hey, we've got work to do!*
+
+ We get it. Really we do.
+ But it is so ridiculously easy to avoid these problems that there is no excuse for doing it wrong.
+
+ ### Inject the *HeroService*
+
+ Two lines replace the one line of *new*:
+ 1. we add a constructor.
+ 1. we add to the component's `providers` metadata
+
+ Here's the constructor:
++makeExample('toh-4/dart/lib/app_component_1.dart', 'ctor', 'app_component.dart (constructor)')
+:marked
+ The constructor itself does nothing. The parameter simultaneously
+ defines a private `_heroService` property and identifies it as a `HeroService` injection site.
+.l-sub-section
+ :marked
+ We prefix private variables with an underscore (_) to warn readers of our code
+ that this variable is not part of the component's public API.
+:marked
+ Now Angular will know to supply an instance of the `HeroService` when it creates a new `AppComponent`.
+
+ Angular has to get that instance from somewhere. That's the role of the Angular *Dependency Injector*.
+ The **Injector** has a **container** of previously created services.
+ Either it finds and returns a pre-existing `HeroService` from its container or it creates a new instance, adds
+ it to the container, and returns it to Angular.
+
+.l-sub-section
+ :marked
+ Learn more about Dependency Injection in the [Dependency Injection](../guide/dependency-injection.html) chapter.
+:marked
+ The *injector* does not know yet how to create a `HeroService`.
+ If we ran our code now, Angular would fail with an error:
+code-example(format="." language="html").
+ EXCEPTION: No provider for HeroService! (AppComponent -> HeroService)
+:marked
+ We have to teach the *injector* how to make a `HeroService` by registering a `HeroService` **provider**.
+ Do that by adding the following `providers` array property to the bottom of the component metadata
+ in the `@Component` call.
+
++makeExample('toh-4/dart/lib/app_component_1.dart', 'providers', 'app_component.dart (providing HeroService)')
+:marked
+ The `providers` array tells Angular to create a fresh instance of the `HeroService` when it creates a new `AppComponent`.
+ The `AppComponent` can use that service to get heroes and so can every child component of its component tree.
+
+.l-sub-section
+ :marked
+ ### Services and the component tree
+
+ Recall that the `AppComponent` creates an instance of `HeroDetail` by virtue of the
+ `` tag at the bottom of its template. That `HeroDetail` is a child of the `AppComponent`.
+
+ If the `HeroDetailComponent` needed its parent component's `HeroService`,
+ it would ask Angular to inject the service into its constructor which would look just like the one for `AppComponent`:
+ +makeExample('toh-4/dart/lib/app_component_1.dart', 'ctor', 'hero_detail_component.dart (constructor)')
+ :marked
+ The `HeroDetailComponent` must *not* repeat it's parent's `providers` array! Guess [why](#shadow-provider).
+
+ The `AppComponent` is the top level component of our application.
+ There should be only one instance of that component and only one instance of the `HeroService` in our entire app.
+:marked
+ ### *getHeroes* in the *AppComponent*
+ We've got the service in a `_heroService` private variable. Let's use it.
+
+ We pause to think. We can call the service and get the data in one line.
++makeExample('toh-4/dart/lib/app_component_1.dart', 'get-heroes')(format=".")
+:marked
+ We don't really need a dedicated method to wrap one line. We write it anyway:
++makeExample('toh-4/dart/lib/app_component_1.dart', 'getHeroes', 'app_component.dart (getHeroes)')(format=".")
+:marked
+ ### The *ngOnInit* Lifecycle Hook
+ `AppComponent` should fetch and display heroes without a fuss.
+ Where do we call the `getHeroes` method? In a constructor? We do *not*!
+
+ Years of experience and bitter tears have taught us to keep complex logic out of the constructor,
+ especially anything that might call a server as a data access method is sure to do.
+
+ The constructor is for simple initializations like wiring constructor parameters to properties.
+ It's not for heavy lifting. We should be able to create a component in a test and not worry that it
+ might do real work — like calling a server! — before we tell it to do so.
+
+ If not the constructor, something has to call `getHeroes`.
+
+ Angular will call it if we implement the Angular **ngOnInit** *Lifecycle Hook*.
+ Angular offers a number of interfaces for tapping into critical moments in the component lifecycle:
+ at creation, after each change, and at its eventual destruction.
+
+ Each interface has a single method. When the component implements that method, Angular calls it at the appropriate time.
+.l-sub-section
+ :marked
+ Learn more about lifecycle hooks in the [Lifecycle Hooks](../guide/lifecycle-hooks.html) chapter.
+:marked
+ Here's the essential outline for the `OnInit` interface:
++makeExample('toh-4/dart/lib/app_component_1.dart', 'on-init', 'app_component.dart (OnInit protocol)')(format=".")
+:marked
+ We write an `ngOnInit` method with our initialization logic inside and leave it to Angular to call it
+ at the right time. In our case, we initialize by calling `getHeroes`.
++makeExample('toh-4/dart/lib/app_component_1.dart', 'ng-on-init', 'app_component.dart (OnInit protocol)')(format=".")
+:marked
+ Our application should be running as expected, showing a list of heroes and a hero detail view
+ when we click on a hero name.
+
+ We're getting closer. But something isn't quite right.
+
+ ## Async Services and Futures
+ Our `HeroService` returns a list of mock heroes immediately.
+ Its `getHeroes` signature is synchronous
++makeExample('toh-4/dart/lib/app_component_1.dart', 'get-heroes')(format=".")
+:marked
+ Ask for heroes and they are there in the returned result.
+
+ Someday we're going to get heroes from a remote server. We don’t call http yet, but we aspire to in later chapters.
+
+ When we do, we'll have to wait for the server to respond and we won't be able to block the UI while we wait,
+ even if we want to (which we shouldn't) because the browser won't block.
+
+ We'll have to use some kind of asynchronous technique and that will change the signature of our `getHeroes` method.
+
+ We'll use *futures*.
+
+ ### The Hero Service returns a future
+
+ We ask an asynchronous service to do some work and give it a callback function.
+ It does that work (somewhere) and eventually it calls our function with the results of the work or an error.
+.l-sub-section
+ :marked
+ We are simplifying. Learn about Futures [here](https://www.dartlang.org/docs/tutorials/futures/).
+:marked
+ Update the `HeroService` with this future-returning `getHeroes` method:
++makeExample('toh-4/dart/lib/hero_service.dart', 'get-heroes', 'hero_service.dart (getHeroes)')(format=".")
+:marked
+ We're still mocking the data. We're simulating the behavior of an ultra-fast, zero-latency server,
+ by returning an **immediately resolved future** with our mock heroes as the result.
+
+ ### Act on the Futures
+ Returning to the `AppComponent` and its `getHeroes` method, we see that it still looks like this:
++makeExample('toh-4/dart/lib/app_component_1.dart', 'getHeroes', 'app_component.dart (getHeroes - old)')(format=".")
+:marked
+ As a result of our change to `HeroService`, we're now setting `heroes` to a future rather than an list of heroes.
+
+ We have to change our implementation to *act on the future when it resolves*.
+ We can *await* the future to resolve, and then display the heroes:
++makeExample('toh-4/dart/lib/app_component.dart', 'get-heroes', 'app_component.dart (getHeroes - revised)')(format=".")
+:marked
+ Our callback sets the component's `heroes` property to the list of heroes returned by the service. That's all there is to it!
+
+ Our app should still be running, still showing a list of heroes, and still
+ responding to a name selection with a detail view.
+.l-sub-section
+ :marked
+ Checkout the "[Take it slow](#slow)" appendix to see what the app might be like with a poor connection.
+:marked
+ ### Review the App Structure
+ Let’s verify that we have the following structure after all of our good refactoring in this chapter:
+
+.filetree
+ .file angular2_tour_of_heroes
+ .children
+ .file lib
+ .children
+ .file app_component.dart
+ .file hero.dart
+ .file hero_detail_component.dart
+ .file hero_service.dart
+ .file mock_heroes.dart
+ .file web
+ .children
+ .file index.html
+ .file main.dart
+ .file pubspec.yaml
+:marked
+ Here are the code files we discussed in this chapter.
+
++makeTabs(`
+ toh-4/dart/lib/hero_service.dart,
+ toh-4/dart/lib/app_component.dart,
+ toh-4/dart/lib/mock_heroes.dart
+ `,'',`
+ lib/hero_service.dart,
+ lib/app_component.dart,
+ lib/mock_heroes.dart
+ `)
+:marked
+ ## The Road We’ve Travelled
+ Let’s take stock of what we’ve built.
+
+ * We created a service class that can be shared by many components
+ * We used the `ngOnInit` Lifecycle Hook to get our heroes when our `AppComponent` activates
+ * We defined our `HeroService` as a provider for our `AppComponent`
+ * We created mock hero data and imported them into our service
+ * We designed our service to return a future and our component to get our data from the future
+
+ [Run the live example for part 4](https://tour-of-heroes.firebaseapp.com/toh4/)
+
+ ### The Road Ahead
+ Our Tour of Heroes has become more reusable using shared components and services.
+ We want to create a dashboard, add menu links that route between the views, and format data in a template.
+ As our app evolves, we’ll learn how to design it to make it easier to grow and maintain.
+ We’ll learn more about these tasks in the coming chapters.
+
+.l-main-section
+
+:marked
+ ### Appendix: Take it slow
+
+ We can simulate a slow connection.
+
+ Add the following `getHeroesSlowly` method to the `HeroService`
++makeExample('toh-4/dart/lib/hero_service.dart', 'get-heroes-slowly', 'hero_service.dart (getHeroesSlowy)')(format=".")
+:marked
+ Like `getHeroes`, it also returns a future.
+ But this future waits 2 seconds before resolving the future with mock heroes.
+
+ Back in the `AppComponent`, swap `_heroService.getHeroesSlowly` for `_heroService.getHeroes`
+ and see how the app behaves.
+
+.l-main-section
+
+:marked
+ ### Appendix: Shadowing the parent's service
+
+ We stated [earlier](#child-component) that if we injected the parent `AppComponent` `HeroService`
+ into the `HeroDetailComponent`, *we must not add a providers array* to the `HeroDetailComponent` metadata.
+
+ Why? Because that tells Angular to create a new instance of the `HeroService` at the `HeroDetailComponent` level.
+ The `HeroDetailComponent` doesn't want its *own* service instance; it wants its *parent's* service instance.
+ Adding the `providers` array creates a new service instance that shadows the parent instance.
+
+ Think carefully about where and when to register a provider.
+ Understand the scope of that registration. Be careful not to create a new service instance at the wrong level.