anchor.diff:  +makeExample('app/crisis-center/crisis-detail-resolve.service.ts', '')
   
   :marked
  -  We'll take the relevant parts of the `ngOnInit` lifecycle hook in our `CrisisDetailComponent` and moved them into our `CrisisDetailResolve` guard.
  +  We'll take the relevant parts of the `ngOnInit` lifecycle hook in our `CrisisDetailComponent` and move them into our `CrisisDetailResolve` guard.
     We import the `Crisis` model and `CrisisService` and also the `Router` for navigation from our resolve implementation. We want to be explicit about
     the data we are resolving, so we implement the `Resolve` interface with a type of `Crisis`. This lets us know that what we will resolve will match our
     `Crisis` model. We inject the `CrisisService` and `Router` and implement the `resolve` method that supports a `Promise`, `Observable` or a synchronous
  
positive.code:   Users update crisis information in the `CrisisDetailComponent`.
    Unlike the `HeroDetailComponent`, the user changes do not update the
    crisis entity immediately. We update the entity when the user presses the *Save* button.
    We discard the changes if the user presses he *Cancel* button.
  
    Both buttons navigate back to the crisis list after save or cancel.
  
  
negative.code:   doing so greatly complicates the pattern matching required to translate an incoming URL to a named route.
  
    Optional parameters are the ideal vehicle for conveying arbitrarily complex information during navigation.
    Optional parameters aren't involved in pattern matching and afford enormous flexibility of expression.
  
    The Router supports navigation with optional parameters as well as required route parameters.
    We define _optional_ parameters in an *object* after we define our required route parameters.
  