This is my final post in a series about building Angular Directives. The purpose is to create a directive which will loop over a list of items, and allow the user to delete one of the items. The result will look something like this:
This post will share some things I do to prepare a directive for reuse between different angular modules. It will cover the restrict property of the directive object, and show you how to put your directive in its own module.
The restrict property defines how a directive can be used. There are four different ways that Angular can find a directive:
- A: If the restrict attribute contains an A, then the directive can be used as an attribute name. It would be used like this:
<div dci-testdirective dataprovider="objectArray"></div>
- E: If the restrict attribute contains an E, then the directive can be used as its own element. This is what we've been doing in this whole article series:
<dci-testdirective dataprovider="objectArray" ></dci-testdirective>
This is my preferred method for using directives.
- C: If the restrict property contains a C, then that directive can be used as part of a CSS class:
<div class="dci-testdirective" dataprovider="objectArray"></div>
- M: If the restrict property specifies M that means the directive can be used as an HTML Comment.
<!-- directive: dci-testdirective expression -->
When using a directive as an HTML comment, there is no easy way to pass in values. The expression mentioned above will be accessible inside the link function as part of the attrs parameter; but the result must be a string; it is not easy to pass in complicated values such as arrays or other dynamic values. Comment directive are the least common and I believe this is why.
If you want your directive to be available in all methods, you can do this:
restrict : 'AECM',
For most practical purposes, I'll do this:
restrict : 'AE',
This makes the directive available as an attribute and as an element.
Put Directive in its own Module
The next thing I want to cover is how to put the directive into its own module. This, basically, gives the directive its own space in the world of Angular applications. That space can be passed around to other modules that need to use it.
First, let's review how the directive is currently defined:
The directive is created using the directive function of an Angular module. The angular module is in this case refers to the main application used throughout this series. We're going to take that directive out of the main application's module and put it in one of its own:
With the directive in its own module, the original application will have no way to access it by default. We need to tell the original a module to reference the new directive-specific module. This is done by adding the directive-specific module as an argument to the main module's definition:
The directiveTestApp module now has an argument in its options array, referring to the module which contains the directive we created in this whitepaper. The HTML code does not need to change.
By implementing directives in their own module, this increases its reusability. With a js include and adding the options argument the directive can be made available to our full application.
This series of articles covered everything you need to know, and more, to get started using directives within your Angular applications. Still, I didn't cover everything. Here are a few areas that you can look into for further study:
- Controllers: Directives can have controllers. These are often used for communication between nested directives, but could also be used similar to the link function.
- Transclusion: An Angular directive can wrap HTML. This is useful because the wrapped HTML is treated as part of the source controller, not part of the directive. It can access scope variables and methods from the controller even though visually it is displayed as part of the directive.