export class DirectiveMetadata

exported from angular2/core defined in angular2/src/core/metadata/directives.ts (line 4)

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:

1. For each directive, the ElementInjector attempts to resolve the directive's constructor arguments.
2. 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, returns null.
  • The platform injector resolves browser singleton resources, such as: cookies, title, location, and others.
• 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:

1. Dependencies on the current element
2. Dependencies on element injectors and their parents until it encounters a Shadow DOM boundary
3. Dependencies on component injectors and their parents until it encounters the root component
4. 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, for DirectiveMetadata directives only
• bindingPropagation: 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 Dependency 6. 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.

@Component({
  selector: 'someDir',
  queries: {
    contentChildren: new ContentChildren(ChildDirective),
    viewChildren: new ViewChildren(ChildDirective)
  },
  template: '<child-directive></child-directive>',
  directives: [ChildDirective]
})
class SomeDir {
  contentChildren: QueryList<ChildDirective>,
  viewChildren: QueryList<ChildDirective>

  ngAfterContentInit() {
    // contentChildren is set
  }

  ngAfterViewInit() {
    // viewChildren is set
  }
}