ng-attr-custom-directive matches with customDirective

[OmarNaghmouchi]

Use case: I wanna append an attribute (directive) depending on a condition.
Using ng-attr-custom-directive to add custom-directive dynamically to an element.

Issue: customDirective matches with ng-attr-custom-directive : My directive is instantiated and 'executed'.
Expected: customDirective doesn't match with ng-attr-custom-directive , after execution of the ng-attr directive, it append or not, depending on the evaluation of the expression, and then, if appended, 'execute' the directive.

A plnkr showing the issue :
https://plnkr.co/edit/J1XKP7XWqvSEa6feoWmR

[Narretz]

I'm not sure if this is expected behavior or not. I tend to say it's not, because Angular usually doesn't allow you to add directives "dynamically". It also doesn't copy the value of the ng-attr-... attributes, so it's not really useful there either. There are also no tests for this behavior. Still, I assume changing this would be a BC, because the behavior has been like this for a long time (although I see no practical use case for relying on that behavior).

[gkalpak]

I don't think it should be able to dymanically add directive's using ng-attr-....
The current behavior was kind of a surprise to me tbh. But then again, it has been like this for a long time and it only affects a very uncommon usecase, so I would probably not break it.

[OmarNaghmouchi]

Maybe it's not the common usecase, but the fact that the compiler matches ng-attr-x with x directive is not normal: As the documentation says:
The normalization process is as follows:
Strip x- and data- from the front of the element/attributes.
Convert the :, -, or _-delimited name to camelCase.

[gkalpak]

@OmarNaghmouchi, this could just be a documentation issue :)

[gkalpak]

Here is how I think about it:

• ng-attr-foo provides a way to dynamically add/remore the foo property.
• Compilation of each element should only happen once, thus we can't dynamically apply/un-apply directives.
• If we wanted to let ng-attr-foo determine whether a [foo] directive gets applied to the element or not, the decision should be made based on the info available at compilation time.
• This would mean that we would need to interpolate based on the current state of the corresponding scope (i.e. before other directives have been compiled/linked, before directive controllers have been instantiated etc).
• That would lead to all sorts of confusing bugs and unexpected behavior.

Such kind of logic seems better suited for either a parent directive's template function or the foo directive's linking functions.

[Narretz]

Afaik, ng-attr-foo doesn't really allow you to remove the foo property - it allows you to add the foo attribute with an interpolated value. If you use it without an interpolated value, it doesn't add foo, and if you have an interpolated value, then there's no way to remove the attribute completely.

So I don' think figuring out if foo gets added is difficult. It'll be added if the attribute contains interpolation.

And @gkalpak I'm not really sure if your comment concludes that you think the current behavior is correct or that we should change it. ;)

[gkalpak]

ng-attr-foo does let you remove the attribute (if it contains interpolation and the interpolated expression evaluates to undefined).

My comment concludes that we should not change the current behavior 😃

[Narretz]

You are right. This should probably be documented somewhere, because I don't find that intuitive.

[OmarNaghmouchi]

My basic problem is with the normalization process. I don't think angular should matches ng-attr-foo with foo as the documentation already said. I Think it's a bug which have to be fixed.

@gkalpak I a almost sure it's not a documentation issue, since it's mentioned at the documentation of the method:

Converts an attribute name (e.g. dash/colon/underscore-delimited string, optionally prefixed with x- or data-) to its normalized, camelCase form.

[gkalpak]

This should probably be documented somewhere, because I don't find that intuitive.

@Narretz, it is.

@OmarNaghmouchi, as I (tried to) explain in #14575 (comment), we can't implement it in a way that is reliable and less unexpected than the current behavior. The problem is the directives should be determined during the compile phase, but ng-attr- can evaluate its expression during the linking phase.