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

This commit is contained in:
Victor Berchet 2016-12-09 05:56:14 -08:00 committed by Ward Bell
parent 50f5a80db1
commit cf97326344
2 changed files with 8 additions and 8 deletions

View File

@ -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;
}
});
}

View File

@ -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
to resolve route data synchronously or asynchronously. In `CrisisDetailComponent`, we used the `ngOnInit` to retrieve the `Crisis`
information. We also navigated the user away from the route if the `Crisis` was not found. It would be more efficient to perform this
The **`Resolve`** interface can be implemented as a service to resolve route data either synchronously or asynchronously.
In `CrisisDetailComponent`, we used the `ngOnInit` to retrieve the `Crisis` information.
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.