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.
DirectiveMetadatas with an embedded view are called ComponentMetadatas.
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 ElementInjectorattempts to resolve the directive's constructor arguments.
- Angular instantiates directives for each matched element using ElementInjectorin 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 Injectorcannot 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 ElementInjectorwhich 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: ElementRefto obtain a reference to logical element in the view.
- viewContainer: ViewContainerRefto control child template instantiation, for- DirectiveMetadatadirectives only
- bindingPropagation: BindingPropagationto 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, Dependency5 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.