fix(router): fix Resolve docs and Resolve.resolve signature (#2954)

public/docs/_examples/router/ts/app/crisis-center/crisis-detail-resolve.service.ts

@@ -1,6 +1,6 @@
 // #docregion
 import { Injectable }             from '@angular/core';
-import { Router, Resolve,
+import { Router, Resolve, RouterStateSnapshot,
          ActivatedRouteSnapshot } from '@angular/router';
 
 import { Crisis, CrisisService } from './crisis.service';
@@ -9,7 +9,7 @@ import { Crisis, CrisisService } from './crisis.service';
 export class CrisisDetailResolve implements Resolve<Crisis> {
   constructor(private cs: CrisisService, private router: Router) {}
 
-  resolve(route: ActivatedRouteSnapshot): Promise<Crisis>|boolean {
+  resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Promise<Crisis> {
     let id = route.params['id'];
 
     return this.cs.getCrisis(id).then(crisis => {
@@ -17,7 +17,7 @@ export class CrisisDetailResolve implements Resolve<Crisis> {
         return crisis;
       } else { // id not found
         this.router.navigate(['/crisis-center']);
-        return false;
+        return null;
       }
     });
   }

public/docs/ts/latest/guide/router.jade

@@ -1927,9 +1927,9 @@ h3#resolve-guard <i>Resolve</i>: pre-fetching component data
   We'll update our `Crisis Detail` route to resolve our Crisis before loading the route, or if the user happens to
   navigate to an invalid crisis center `:id`, we'll navigate back to our list of existing crises.
 
-  Like the `CanActivate` and `CanDeactivate` guards, the **`Resolve`** guard is an interface we can implement as a service
+  The **`Resolve`** interface can be implemented as a service to resolve route data either synchronously or asynchronously.
-  to resolve route data synchronously or asynchronously. In `CrisisDetailComponent`, we used the `ngOnInit` to retrieve the `Crisis`
+  In `CrisisDetailComponent`, we used the `ngOnInit` to retrieve the `Crisis` information.
-  information. We also navigated the user away from the route if the `Crisis` was not found. It would be more efficient to perform this
+  We also navigated the user away from the route if the `Crisis` was not found. It would be more efficient to perform this
   action before the route is ever activated.
 
   We'll create a `CrisisDetailResolve` service that will handle retrieving the `Crisis` and navigating the user away if the `Crisis` does
@@ -1957,7 +1957,7 @@ h3#resolve-guard <i>Resolve</i>: pre-fetching component data
 +makeExcerpt('app/crisis-center/crisis-center-routing.module.4.ts (resolve)', 'crisis-detail-resolve')
 
 :marked
-  Now that we've added our `Resolve` guard to fetch data before the route loads, we no longer need to do this once we get into our `CrisisDetailComponent`.
+  Now that we've added our `Resolve` resolver to fetch data before the route loads, we no longer need to do this once we get into our `CrisisDetailComponent`.
   We'll update the `CrisisDetailComponent` to use the `ActivatedRoute` data, which is where our `crisis` property from our `Resolve` guard will be provided.
   Once activated, all we need to do is set our local `crisis` and `editName` properties from our resolved `Crisis` information. The `Crisis` is being provided
   at the time the route component is activated.
@@ -1968,7 +1968,7 @@ h3#resolve-guard <i>Resolve</i>: pre-fetching component data
   **Two critical points**
   1. The router interface is optional. We don't inherit from a base class. We simply implement the interface method or not.
 
-  1. We rely on the router to call the guard. We don't worry about all the ways that the user
+  1. We rely on the router to call the resolver. We don't worry about all the ways that the user
   could navigate away. That's the router's job.
   We simply write this class and let the router take it from there.