Angular directives - element or attribute?

Question

I'm part of a team with about 6 UI devs, of varying quality and next to no Angular experience. Many are contractors, with little experience with the code base. The app has a very fancy (complicated) UI. It supports IE8+ (soon hopefully IE9+).

We're introducing Angular for a major extension to the app, and I've been asked to write guidelines on the use of Angular for the team.

We'll use directives to create fancy UI elements, all prefixed with "ipwr" to avoid name clashes. I'm trying to decide whether to mandate that devs give their directives the restriction "element" or "attribute". Mandating only one, to avoid chaos and confusion.

My question is: what restrict is better or more popular for directives, "element" or "attribute"? My main concern is ease of use for people with little Angular experience who are new to the application code base, to reduce bugs, copy and paste behaviour, etc.

Answer 1

The angular guidance says that you should use the "element" restriction whenever the directive has full control over it's template meaning it has a template that it is rendering out, etc.

For attributes, they suggest to use these only when you are adding "behavior" to an existing element or decorating an existing element.

For example, think of the ng-click directive, this is used a attribute not as a element because the click directive is just adding the click behavior to some element.

Another example would be the ng-repeat directive, it is also used as an attribute not as a element because it is going to repeat the element in which it is being used in.

Now, this guidance is from the angular documentation; however, I don't know necessarily that element vs. attribute is going to give you a "better" approach it's more of a convention.

Now if you have to support older browsers, then you may want to consider using either the comment or class directives.

My personal preference is to just use the attribute restriction; mainly because people that are new to angular get overwhelmed at first when they see the restrict and it's variations of the options that can be used.

Answer 2

I usually defer to the John Papa AngularJS style guide when making these types of decisions. He says:

Lean towards implementing as an element when its standalone and as an attribute when it enhances its existing DOM element.

Answer 3

If you want to keep your HTML valid you'd use attributes, e.g. if you have a directive ipwr-modal, you can declare it as <div data-ipwr-modal="you-could-put-some-binding-here"></div>.

When creating directives with a custom layout, however, you'd better use element declaration (if you don't need to have your HTML valid). This is the more obvious way to say: "hey, we have a custom component here".

This blog post explains it with some more ideas

Answer 4

Some points to consider:

1. Most of the time attributes is the best/most convenient option (it's not the default by chance).

2. Anything you can do with element-bound directives, you can do with attribute-bound as well.

3. Element-bound directives can be more descriptive/readable at times.

4. If you want your code to pass certain types of validation, you should use attributes.

5. Since you want to support IE8, keep in mind that custom tags have an extra overhead (more info), which hurts maintainability.

---

_{BTW, you can't limit directives to elements only (without affecting functionality), so it is more a question of allowing 'element' or not. Note that an element often has more than one directives and directives placed on the same element can cooperate and augment each other's behaviour. So limiting the use of directives to 'element', means limiting the number of custom directives per element to 1, which severly reduces the functionality-potential.}

---

That said, this is what I ('d) do:

• If IE8 is not an issue, allow both (mostly use attributes).

• If IE8 (or the overhead for custom tags) is an issue, use only attributes.

• In general, if only one form should be allowed, it should be attributes (works anywhere, no extra overhead, offers all functionality).