export Directive : DirectiveFactory
export Directive : DirectiveFactory
exported from angular2/core defined in angular2/src/core/metadata.ts (line 889)
Directives allow you to attach behavior to elements in the DOM.
DirectiveMetadata
s with an embedded view are called ComponentMetadata
s.
A directive consists of a single directive annotation and a controller class. When the
directive's selector
matches
elements in the DOM, the following steps occur:
- For each directive, the
ElementInjector
attempts to resolve the directive's constructor arguments. - Angular instantiates directives for each matched element using
ElementInjector
in a depth-first order, as declared in the HTML.
Understanding How Injection Works
There are three stages of injection resolution.
- Pre-existing Injectors:
- The terminal
Injector
cannot resolve dependencies. It either throws an error or, if the dependency was specified as@Optional
, returnsnull
. - The platform injector resolves browser singleton resources, such as: cookies, title, location, and others.
- The terminal
- Component Injectors: Each component instance has its own
Injector
, and they follow the same parent-child hierarchy as the component instances in the DOM. - Element Injectors: Each component instance has a Shadow DOM. Within the Shadow DOM each
element has an
ElementInjector
which follow the same parent-child hierarchy as the DOM elements themselves.
When a template is instantiated, it also must instantiate the corresponding directives in a
depth-first order. The
current ElementInjector
resolves the constructor dependencies for each directive.
Angular then resolves dependencies as follows, according to the order in which they appear in the
ViewMetadata
:
- Dependencies on the current element
- Dependencies on element injectors and their parents until it encounters a Shadow DOM boundary
- Dependencies on component injectors and their parents until it encounters the root component
- Dependencies on pre-existing injectors
The ElementInjector
can inject other directives, element-specific special objects, or it can
delegate to the parent
injector.
To inject other directives, declare the constructor parameter as:
directive:DirectiveType
: a directive on the current element only@Host() directive:DirectiveType
: any directive that matches the type between the current element and the Shadow DOM root.@Query(DirectiveType) query:QueryList<DirectiveType>
: A live collection of direct child directives.@QueryDescendants(DirectiveType) query:QueryList<DirectiveType>
: A live collection of any child directives.
To inject element-specific special objects, declare the constructor parameter as:
element: ElementRef
to obtain a reference to logical element in the view.viewContainer: ViewContainerRef
to control child template instantiation, forDirectiveMetadata
directives onlybindingPropagation: BindingPropagation
to control change detection in a more granular way.
Example
The following example demonstrates how dependency injection resolves constructor arguments in practice.
Assume this HTML template:
With the following dependency
decorator and SomeService
injectable class.
Let's step through the different ways in which MyDirective
could be declared...
No injection
Here the constructor is declared with no arguments, therefore nothing is injected into
MyDirective
.
This directive would be instantiated with no dependencies.
Component-level injection
Directives can inject any injectable instance from the closest component injector or any of its parents.
Here, the constructor declares a parameter, someService
, and injects the SomeService
type
from the parent
component's injector.
This directive would be instantiated with a dependency on SomeService
.
Injecting a directive from the current element
Directives can inject other directives declared on the current element.
This directive would be instantiated with Dependency
declared at the same element, in this case
dependency="3"
.
Injecting a directive from any ancestor elements
Directives can inject other directives declared on any ancestor element (in the current Shadow DOM), i.e. on the current element, the parent element, or its parents.
@Host
checks the current element, the parent, as well as its parents recursively. If
dependency="2"
didn't
exist on the direct parent, this injection would
have returned
dependency="1"
.
Injecting a live collection of direct child directives
A directive can also query for other child directives. Since parent directives are instantiated
before child directives, a directive can't simply inject the list of child directives. Instead,
the directive injects a QueryList
, which updates its contents as children are added,
removed, or moved by a directive that uses a ViewContainerRef
such as a ngFor
, an
ngIf
, or an ngSwitch
.
This directive would be instantiated with a QueryList
which contains Dependency
4 and
- Here,
Dependency
5 would not be included, because it is not a direct child.
Injecting a live collection of descendant directives
By passing the descendant flag to @Query
above, we can include the children of the child
elements.
This directive would be instantiated with a Query which would contain Dependency
4, 5 and 6.
Optional injection
The normal behavior of directives is to return an error when a specified dependency cannot be
resolved. If you
would like to inject null
on unresolved dependency instead, you can annotate that dependency
with @Optional()
.
This explicitly permits the author of a template to treat some of the surrounding directives as
optional.
This directive would be instantiated with a Dependency
directive found on the current element.
If none can be
found, the injector supplies null
instead of throwing an error.
Example
Here we use a decorator directive to simply define basic tool-tip behavior.
In our HTML template, we can then add this behavior to a <div>
or any other element with the
tooltip
selector,
like so:
Directives can also control the instantiation, destruction, and positioning of inline template elements:
A directive uses a ViewContainerRef
to instantiate, insert, move, and destroy views at
runtime.
The ViewContainerRef
is created as a result of <template>
element, and represents a
location in the current view
where these actions are performed.
Views are always created as children of the current ViewMetadata
, and as siblings of the
<template>
element. Thus a
directive in a child view cannot inject the directive that created it.
Since directives that create views via ViewContainers are common in Angular, and using the full
<template>
element syntax is wordy, Angular
also supports a shorthand notation: <li *foo="bar">
and <li template="foo: bar">
are
equivalent.
Thus,
Expands in use to:
Notice that although the shorthand places *foo="bar"
within the <li>
element, the binding for
the directive
controller is correctly instantiated on the <template>
element rather than the <li>
element.
Lifecycle hooks
When the directive class implements some lifecycle_hooks the callbacks are called by the change detection at defined points in time during the life of the directive.
Example
Let's suppose we want to implement the unless
behavior, to conditionally include a template.
Here is a simple directive that triggers on an unless
selector:
We can then use this unless
selector in a template:
Once the directive instantiates the child view, the shorthand notation for the template expands and the result is:
Note also that although the <li></li>
template still exists inside the <template></template>
,
the instantiated
view occurs on the second <li></li>
which is a sibling to the <template>
element.