` element into the directive's constructor which sets the `
` element's background style to yellow. - - -{@a respond-to-user} ## Respond to user-initiated events Currently, `myHighlight` simply sets an element color. @@ -152,14 +155,10 @@ and respond by setting or clearing the highlight color. Begin by adding `HostListener` to the list of imported symbols; add the `Input` symbol as well because you'll need it soon. - -{@example 'attribute-directives/ts/src/app/highlight.directive.ts' region='imports'} - -Then add two eventhandlers that respond when the mouse enters or leaves, each adorned by the `HostListener` !{_decorator}. - -{@example 'attribute-directives/ts/src/app/highlight.directive.2.ts' region='mouse-methods'} - -The `@HostListener` !{_decorator} lets you subscribe to events of the DOM element that hosts an attribute directive, the `
` in this case. +Then add two eventhandlers that respond when the mouse enters or leaves, +each adorned by the `HostListener` !{_decorator}. +The `@HostListener` !{_decorator} lets you subscribe to events of the DOM +element that hosts an attribute directive, the `
` in this case.
Of course you could reach into the DOM with standard JavaScript and and attach event listeners manually.
There are at least three problems with _that_ approach:
@@ -169,24 +168,19 @@ There are at least three problems with _that_ approach:
1. Talking to DOM API directly isn't a best practice.
The handlers delegate to a helper method that sets the color on the DOM element, `#{_priv}el`,
which you declare and initialize in the constructor.
-
-
-{@example 'attribute-directives/ts/src/app/highlight.directive.2.ts' region='ctor'}
-
Here's the updated directive in full:
+
{@example 'attribute-directives/ts/src/app/highlight.directive.2.ts'}
-Run the app and confirm that the background color appears when the mouse hovers over the `p` and
-disappears as it moves out.
+Run the app and confirm that the background color appears when
+the mouse hovers over the `p` and disappears as it moves out.
+
` element
and sets the directive's highlight color with a property binding.
You're re-using the directive's attribute selector (`[myHighlight]`) to do both jobs.
That's a crisp, compact syntax.
You'll have to rename the directive's `highlightColor` property to `myHighlight` because that's now the color property binding name.
-
-{@example 'attribute-directives/ts/src/app/highlight.directive.2.ts' region='color-2'}
-
This is disagreeable. The word, `myHighlight`, is a terrible property name and it doesn't convey the property's intent.
@@ -244,60 +220,54 @@ _Inside_ the directive the property is known as `highlightColor`.
_Outside_ the directive, where you bind to it, it's known as `myHighlight`.
You get the best of both worlds: the property name you want and the binding syntax you want:
-
-{@example 'attribute-directives/ts/src/app/app.component.html' region='color'}
-
Now that you're binding to `highlightColor`, modify the `onMouseEnter()` method to use it.
-If someone neglects to bind to `highlightColor`, highlight in "red" by default.
+If someone neglects to bind to `highlightColor`, highlight in red:
+Here's the latest version of the directive class.
+## Write a harness to try it
-
-{@example 'attribute-directives/ts/src/app/highlight.directive.3.ts' region='mouse-enter'}
-
-Here's the latest version of the directive class.## Write a harness to try itIt may be difficult to imagine how this directive actually works.
+It may be difficult to imagine how this directive actually works.
In this section, you'll turn `AppComponent` into a harness that
lets you pick the highlight color with a radio button and bind your color choice to the directive.
-Update `app.component.html` as follows:
-Revise the `AppComponent.color` so that it has no initial value.Here is the harness and directive in action.
+Update app.component.html as follows:
+Revise the `AppComponent.color` so that it has no initial value.
+Here are the harness and directive in action.
+
-### Injector bubbling
+### Injector bubbling
When a component requests a dependency, Angular tries to satisfy that dependency with a provider registered in that component's own injector.
If the component's injector lacks the provider, it passes the request up to its parent component's injector.
@@ -51,22 +51,24 @@ If it runs out of ancestors, Angular throws an error.
You can cap the bubbling. An intermediate component can declare that it is the "host" component.
The hunt for providers will climb no higher than the injector for that host component.
-This a topic for another day.
+This is a topic for another day.
### Re-providing a service at different levels
+
You can re-register a provider for a particular dependency token at multiple levels of the injector tree.
-You don't *have* to re-register providers. You shouldn't do so unless you have a good reason.
+You don't *have* to re-register providers. You shouldn't do so unless you have a good reason.
But you *can*.
As the resolution logic works upwards, the first provider encountered wins.
Thus, a provider in an intermediate injector intercepts a request for a service from something lower in the tree.
It effectively "reconfigures" and "shadows" a provider at a higher level in the tree.
-If you only specify providers at the top level (typically the root `AppModule`), the tree of injectors appears to be flat.
+If you only specify providers at the top level (typically the root `AppModule`), the tree of injectors appears to be flat.
All requests bubble up to the root NgModule injector that you configured with the `!{_bootstrapModule}` method.
## Component injectors
The ability to configure one or more providers at different levels opens up interesting and useful possibilities.
+
### Scenario: service isolation
Architectural reasons may lead you to restrict access to a service to the application domain where it belongs.
@@ -74,57 +76,55 @@ Architectural reasons may lead you to restrict access to a service to the applic
The guide sample includes a `VillainsListComponent` that displays a list of villains.
It gets those villains from a `VillainsService`.
-While you could provide `VillainsService` in the root `AppModule` (that's where you'll find the `HeroesService`),
+While you _could_ provide `VillainsService` in the root `AppModule` (that's where you'll find the `HeroesService`),
that would make the `VillainsService` available everywhere in the application, including the _Hero_ workflows.
-If you later modify the `VillainsService`, you could break something in a hero component somewhere.
-That's not supposed to happen but the way you've provided the service creates that risk.
+If you later modified the `VillainsService`, you could break something in a hero component somewhere.
+That's not supposed to happen but providing the service in the root `AppModule` creates that risk.
Instead, provide the `VillainsService` in the `providers` metadata of the `VillainsListComponent` like this:
-
-
-{@example 'hierarchical-dependency-injection/ts/src/app/villains-list.component.ts' region='metadata'}
-
-By providing `VillainsService` in the `VillainsListComponent` metadata — and nowhere else —,
+By providing `VillainsService` in the `VillainsListComponent` metadata and nowhere else,
the service becomes available only in the `VillainsListComponent` and its sub-component tree.
It's still a singleton, but it's a singleton that exist solely in the _villain_ domain.
-You are confident that a hero component can't access it. You've reduced your exposure to error.
+Now you know that a hero component can't access it. You've reduced your exposure to error.
### Scenario: multiple edit sessions
Many applications allow users to work on several open tasks at the same time.
-For example, in a tax preparation application, the preparer could be working several tax returns,
+For example, in a tax preparation application, the preparer could be working on several tax returns,
switching from one to the other throughout the day.
This guide demonstrates that scenario with an example in the Tour of Heroes theme.
Imagine an outer `HeroListComponent` that displays a list of super heroes.
-To open a hero's tax return, the preparer clicks on a hero name, which opens a component for editing that return.
+To open a hero's tax return, the preparer clicks on a hero name, which opens a component for editing that return.
Each selected hero tax return opens in its own component and multiple returns can be open at the same time.
-Each tax return component
-* is its own tax return editing session.
-* can change a tax return without affecting a return in another component.
-* has the ability to save the changes to its tax return or cancel them.
+Each tax return component has the following characteristics:
+* Is its own tax return editing session.
+* Can change a tax return without affecting a return in another component.
+* Has the ability to save the changes to its tax return or cancel them.
<router-outlet>) that marks where the router should display a view.
+ The directive (<router-outlet>) that marks where the router displays a view.
routerLink contained on or inside the element becomes active/inactive.
+
+
+{@a child-routing-component}
### Child routing component
Add the following `crisis-center.component.ts` to the `crisis-center` folder:
-Much like the `AppComponent`, the `CrisisCenterComponent` is the
+The `CrisisCenterComponent` has the following in common with the `AppComponent`:
-- *Root* of the crisis center area,
-just as `AppComponent` is the root of the entire application
-- *Shell* for the crisis management feature area,
-just as the `AppComponent` is a shell to manage the high-level workflow
+- It is the *root* of the crisis center area,
+just as `AppComponent` is the root of the entire application.
+- It is a *shell* for the crisis management feature area,
+just as the `AppComponent` is a shell to manage the high-level workflow.
Like most shells, the `CrisisCenterComponent` class is very simple, simpler even than `AppComponent`:
it has no business logic, and its template has no links, just a title and
@@ -1682,6 +1789,9 @@ it has no business logic, and its template has no links, just a title and
Unlike `AppComponent`, and most other components, it _lacks a selector_.
It doesn't _need_ one since you don't *embed* this component in a parent template,
instead you use the router to *navigate* to it.
+
+
+{@a child-route-config}
### Child route configuration
The `CrisisCenterComponent` is a *routing component* like the `AppComponent`.
@@ -1757,7 +1867,7 @@ If you changed the parent `/crisis-center` path, you would have to change the li
You can free the links from this dependency by defining paths that are **relative** to the current URL segment.
Navigation _within_ the feature area remains intact even if you change the parent route path to the feature.
-Here's an example
+Here's an example:
The router supports directory-like syntax in a _link parameters list_ to help guide route name lookup:
@@ -1775,6 +1885,9 @@ After the _link parameters array_, add an object with a `relativeTo` property se
The router then calculates the target URL based on the active route's location.
**Always** specify the complete _absolute_ path when calling router's `navigateByUrl` method.
+
+
+{@a nav-to-crisis}
### Navigate to crisis detail with a relative URL
Update the *Crisis List* `onSelect` method to use relative navigation so you don't have
@@ -1786,7 +1899,7 @@ If you were using a `RouterLink` to navigate instead of the `Router` service, yo
link parameters array, but you wouldn't provide the object with the `relativeTo` property.
The `ActivatedRoute` is implicit in a `RouterLink` directive.
Update the `gotoCrises` method of the `CrisisDetailComponent` to navigate back to the *Crisis Center* list using relative path navigation.
-Notice that the path goes up a level (`../`) syntax.
+Notice that the path goes up a level using the `../` syntax.
If the current crisis `id` is `3`, the resulting path back to the crisis list is `/crisis-center/;id=3;foo=foo`.
@@ -1803,7 +1916,7 @@ Clearly you can't put the popup in the same outlet as the other pages.
Until now, you've defined a single outlet and you've nested child routes
under that outlet to group routes together.
-The router only supports one primary _unnamed_ outlet per template,
+The router only supports one primary _unnamed_ outlet per template.
A template can also have any number of _named_ outlets.
Each named outlet has its own set of routes with their own components.
@@ -1821,7 +1934,7 @@ Named outlets are the targets of _secondary routes_.
Secondary routes look like primary routes and you configure them the same way.
They differ in a few key respects.
-* They are independent of each other
+* They are independent of each other.
* They work in combination with other routes.
* They are displayed in named outlets.
@@ -1850,21 +1963,23 @@ Here's the component and its template:
-