@@ -779,7 +779,7 @@ code-example(format="." language="bash").
779
779
the value `15` in the path clearly distinguishes the route to "Magneta" from
780
780
a route for some other hero.
781
781
782
- An [optional-route-parameter](#optional-route-parameter ) might be a better choice if we were passing an *optional* value to `HeroDetailComponent`.
782
+ An [optional-route-parameter](#optional-route-parameters ) might be a better choice if we were passing an *optional* value to `HeroDetailComponent`.
783
783
784
784
a#navigate
785
785
:marked
@@ -986,7 +986,7 @@ figure.image-display
986
986
doing so greatly complicates the pattern matching required to translate an incoming URL to a named route.
987
987
988
988
Optional parameters are the ideal vehicle for conveying arbitrarily complex information during navigation.
989
- Optional parameters aren't involved in pattern matching and affords enormous flexibility of expression.
989
+ Optional parameters aren't involved in pattern matching and afford enormous flexibility of expression.
990
990
991
991
The Router supports navigation with optional parameters as well as required route parameters.
992
992
We define _optional_ parameters in an *object* after we define our required route parameters.
@@ -1817,7 +1817,7 @@ h3#can-deactivate-guard <i>CanDeactivate</i>: handling unsaved changes
1817
1817
Users update crisis information in the `CrisisDetailComponent`.
1818
1818
Unlike the `HeroDetailComponent`, the user changes do not update the
1819
1819
crisis entity immediately. We update the entity when the user presses the *Save* button.
1820
- We discard the changes if the user presses he *Cancel* button.
1820
+ We discard the changes if the user presses the *Cancel* button.
1821
1821
1822
1822
Both buttons navigate back to the crisis list after save or cancel.
1823
1823
@@ -1922,7 +1922,7 @@ h3#resolve-guard <i>Resolve</i>: pre-fetching component data
1922
1922
+ makeExample('app/crisis-center/crisis-detail-resolve.service.ts' , '' )
1923
1923
1924
1924
:marked
1925
- We'll take the relevant parts of the `ngOnInit` lifecycle hook in our `CrisisDetailComponent` and moved them into our `CrisisDetailResolve` guard.
1925
+ We'll take the relevant parts of the `ngOnInit` lifecycle hook in our `CrisisDetailComponent` and move them into our `CrisisDetailResolve` guard.
1926
1926
We import the `Crisis` model and `CrisisService` and also the `Router` for navigation from our resolve implementation. We want to be explicit about
1927
1927
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
1928
1928
`Crisis` model. We inject the `CrisisService` and `Router` and implement the `resolve` method that supports a `Promise`, `Observable` or a synchronous
0 commit comments