Feature Request: Programmatically add directives to another directive's elements before they get compiled.

[trusktr]

I ran into an issue. So far as I know, Angular doesn't have a mechanism by which to address it easily.

http://ngmodules.org has some awesome modules. They are really easy to use, but if they don't expose any events to you, then you're out of luck if you don't want to actually modify the 3rd party module's source code.

What if Angular had an easy way to attach directives to the element of another directive programmatically (before it and any sub-templates get compiled) so that one could use third party directives and not worry if they've exposed any useful features like like event handling mechanism (e.g. they don't use ngClick on any elements)?

For example, here's an example:

Suppose we use someone's awesomeDirective.

<div data-awesome-directive="awesome.data"></div>

This nice directive generates some type of awesome HTML widget with HTML that is defined in the 3rd party source code, perhaps a twitter feed, a profile badge, or something else awesome, but the author of the directive did not include any way to handle click events, etc!

We could step away from Angular, and use jQuery to make a click handler like

$("#awesomeWidget").on("click", function() {/* ... */});

but we don't want to leave the world of Angular awesomeness!

Perhaps, a new addition to the Module.directive API can be added to Angular so one can add a directive to any other directive's elements, like so:

angular.element(document).ready(function() {

    // create your app with a dependency on a 3rd party module.
    var myApp = angular.module("myApp", ["awesomeModuleContainingAwesomeDirective"]);

    // the 3rd party module contains an awesomeDirective.

    // create a custom directive:
    myApp.directive("customDirective", function() {
            return { // set up directive properties like normal.
                restrict: "A",
                scope: {/* ... */},
                // etc...
            };
        });

    // attach the custom directive to the elements of another directive:
    myApp.directive("awesomeDirective") // get the directive.
        .attachDirective(".elements", "customDirective");

    // the first argument to attachDirective() is a standard jQuery selector.
    // internally, Angular would use jQuery's .find(".element")

    // add an already-existing directive  to the elements of another directive:
    var awesomeDirective = myApp.directive("awesomeDirective"); // gets the directive.
    awesomeDirective.attachDirective(".otherElements", "ngCloak");

    // use a third argument for directives that accept an attribute expression:
    awesomeDirective.attachDirective("#oneElement", "ngClick", "count = count + 1");

    angular.bootstrap(document, ["myApp"]);

    /*
     * This would be absolutely pure awesome.
     */
});

This would be a nice way to extend directives that you are using in your app... But what if you want to attach directives to only specific instances of another directive? Then:

    myApp.directive("awesomeDirective") // gets the directive.
        .attachDirective([".rootElements", ".elements"], 'ngClick', "count = count + 1");
    // ^ still no more than 3 arguments

The first argument in this case is an array. The first element in the array tells Angular that we wish to attach our directive to elements matching the awesomeDirective only if those elements are .rootElements. All .rootElements that match the awesomeDirective will then have the ngClick directive applied to sub elements of the class elements using jQuery's .find('.elements').

Angular could benefit from something like this! And it would not only be useful for event handling that 3rd party modules haven't exposed, but for augmenting 3rd party directives with all sorts of other functionality.

[lgalfaso]

You can define multiple directives for a given element name/attribute/class/comment and all of them will be invoked. On top of this, a directive can be intercepted and modified. These two mechanisms should solve a big chunk of these issues.

For more complex cases this is harder to fully handle them in a generic way, #6781 is an attempt to doing so but this may or may not be part of 1.3. (BTW, 2.0 will have something like this but not 100% compatible)

[lgalfaso]

Hi @trusktr

You can define multiple directives for a given element name/attribute/class/comment and all of them will be invoked.

If module A defines a directive on <a> and another module defines another directive also on <a>, then both will be applied to the same <a> element. This is, you can already use the existing elements from another library and build on top (this is, with some limitations) as the communication between both directives can only be done thru the API that each directive exposes.

On top of this, a directive can be intercepted and modified.

You can modify a directive by defining a decorator on the original directive. The API is defined here http://docs.angularjs.org/api/auto/object/$provide
This allows you to change the directive before it reaches the compiler

#6781 and the design changes for 2.0 are something else, and they aim at other things that cannot be done using the previous two mechanism

[trusktr]

You can define multiple directives for a given element name/attribute/class/comment and all of them will be invoked. On top of this, a directive can be intercepted and modified.

I'm not quite sure what you mean. Can you link to the docs for those two points? Or can you provide two quick examples to see if we mean the same thing?

EDIT: after reading the design doc, I think I see what you mean about "defining multiple directives for a given element name/attribute/class/comment". I think you mean something along the lines of how the directive annotations like @TemplateDirective use selectors to define which elements they can apply to. Is that what you mean? If so, that is something independent of what I'm proposing. I'm also still not clear on what directive collectors and extractors are, but they don't seem like part of the public API.

I also looked at PR #6781 and I don't know what those are yet. I've been learning Angular for the first time based on the public API documentation.

What I'm proposing here is simply an easy to use public API, which I haven't seen in the docs, and which can perhaps be done with private, undocumented API that already exists.

The API I'm proposing here is really simple to use, and won't change current usage of Angular, only add to it. :D

I looked through the AngularJS 2.0 design document, and I didn't see anything that specifically addressed this need. The only thing that came close was this:

Binding to events of elements or directives

Syntax: @on-[eventname]="[expression]"

Example:

Semantic: Executes the expression (doSomething()) whenever the event (click) is fired on the element.

Why:

It allows us to bind to any third party event system, which is based on DOM events.If a directive declares a new event, we don't need a new directive to listen to it.Could be used to bridge to jQuery custom events (would require jQuery event bridge). Can be implemented using event delegation (a single top level handler for all event types, rather than each element having its own handler). This is faster, uses less memory.

This implies that 3rd party events already exist. But 3rd party events are not always guaranteed. Being to attach directives like I've proposed would be extremely useful for events that don't exist, as well as for other use cases that can take advantage of the improvements described in the design doc (e.g. the new decorative, template, and component directive design).

[trusktr]

@lgalfaso Hi!

If module A defines a directive on <a> and another module defines another directive also on <a>, then both will be applied to the same <a> element. This is, you can already use the existing elements from another library and build on top (this is, with some limitations) as the communication between both directives can only be done thru the API that each directive exposes.

So you mean if I have

<div data-awesome-directive="awesome.data"></div>

that I can do the following?

<div data-awesome-directive="awesome.data" data-my-own-directive="my.data"></div>

If so, I knew that already, but does it let me add directives to elements of the 3rd party directive?

Suppose that the 3rd party awesomeDirective generates a table. For example,

<div data-awesome-directive="awesome.data"></div>

generates

<div data-awesome-directive="awesome.data">
    <table>
       <tr>
         <td>one</td>
         <td>two</td>
         <td>three</td>
       </tr>
    </table>
</div>

And suppose that I want to do something whenever a user clicks on a <td> element of that generated table. Is this possible to do without modifying the 3rd party library?

Are you saying that if I attach my own directive to the parent element where I've attached the 3rd party directive

<div data-awesome-directive="awesome.data" data-my-own-directive="my.data"></div>

that my custom directive can have access to the elements generated by the 3rd party directive in order to apply ngClick to them?

What I'm aiming for is the effect of having ngClick applied to each <td>, so the effect would be something like this:

<div data-awesome-directive="awesome.data">
    <table>
       <tr>
         <td ng-click="function()">one</td>
         <td ng-click="function()">two</td>
         <td ng-click="function()">three</td>
       </tr>
    </table>
</div>

but I obviously don't want to edit the 3rd party library to add those ng-click directives.

Does such a mechanism exist so that I can make the 3rd party's generated elements have the ngClick directives applied to them before compilation? If so, could you provide an example of how it's done?

Thanks!

[lgalfaso]

Hi,

I mean that if you have

<div data-awesome-directive="awesome.data"></div>

you can add another directive named awesomeDirective and this will be called too. You will not override the existing directive, both will be called.

For the example you just post, you can also create a directive on the td that would know when it is inside an awesomeDirective (check require at http://docs.angularjs.org/api/ng/service/$compile) and will add the click when this is the case

[trusktr]

@lgalfaso Thank you for linking to this document. I was looking for a more in depth guide on Directives in the Angular documentation but I couldn't find it because I was looking for something with the keyword "directive" in the title, not "compile".

I read through the whole thing, and I see what the require property does. I already see two problems with this:

1. The directive being required must have a controller, thus not every directive can be required. In my proposed API, you can attach any directive. It would be have just as if you wrote the attribute onto the element your self (except you did it programmatically because you didn't have access to the HTML of the 3rd party directive).
2. The require property only searches for the required directive in the same element on which we are setting the require property, or a parent element. If I understand correctly, It does not have anything to do with child elements, and thus there is no way to physically put a customDirective onto an element you have no control over.

Can you explain how I would put a customDirective onto each <td> element generated by the awesomeDirective in my example? Can you explain how (if awesomeDirective does not have a controller) we can possibly use require to add an ngClick to each <td> generated by awesomeController? From what I read in that $compile guide it doesn't seem possible.

The API that I've proposed above would be simple to use and straight forward. It would be the next easiest way to add directives to elements (of a 3rd party directive for example), the easiest way being to actually write the <html><tags with-directives="literally">. What I've proposed would work with any directive no matter what type it is. We're not talking about directives that rely on other directives (using require), we're talking about simply adding a plain-ol' directive to an HTML element that happens to not be accessible to you in your text editor (because it's in a 3rd party directive and gets generated by the directive, not by your typing).

[lgalfaso]

@trusktr I do not want to put any false hope here, but the modifications you are proposing have many side-effects. On top, I think that all this can be implemented using an external library without any change to the core.

The directive being required must have a controller, thus not every directive can be required. In my proposed API, you can attach any directive. It would be have just as if you wrote the attribute onto the element your self (except you did it programmatically because you didn't have access to the HTML of the 3rd party directive).

You can add a controller with a decorator or adding another directive

The require property only searches for the required directive in the same element on which we are setting the require property, or a parent element. If I understand correctly, It does not have anything to do with child elements, and thus there is no way to physically put a customDirective onto an element you have no control over.

You can add a directive to the child element, this new directive will check if it can find a parent controller and if that is the case do the needed, if not, do nothing

This is turning into support and not a real issue with Angular, so I am going to close this

[trusktr]

@lgalfaso Thanks for the useful hint on $provide.decorator! Unfortunately, the $provide.decorator mechanism is overly complex for the need at hand. The examples on the home page of AngularJS all have one thing in common: they show how easy it is to make applications by applying directives onto HTML elements. AngularJS needs a simple, programmatic extension of this because access to HTML isn't always guaranteed in development. Access to 3rd party modules isn't guaranteed either.

I went and did extensive research on $provide.decorator after you mentioned it (short of reading the AngularJS implementation). The decorator service does provide some flexibility in modifying the behavior of another directive, but it has limitations:

1. It is overly complex for what I want to do. I was trying to use AngularJS instead of jQuery to reduce the complexity of web app development, not increase it. Developing an Angular app with your own code is easy, but if you try to use 3rd party directives that you need to extend, the complexity comes back. AngularJS needs to make working with 3rd party directives more friendly. Otherwise I might as well just step out of Angular and use jQuery, which defeats the very purpose of using Angular.
2. It is not well documented. Searching for examples on how to use the decorator service led me to other sites other than angularjs.org. Sure, if I find time, I'd love to suggest some documentation. An addition to the PhoneCat tutorial showing how to decorate would be nice.
3. It may require me to know intimately how a complex directive (that I possibly didn't write) works just to make a potentially simple and small change. We should not need to know the implementation of a directive (i.e. class) in order to use it and to extend it.
4. The decorator can only decorate directives defined inside the same module where the decorator is used (I found that info here in the "Conclusion" section near bottom, please correct if wrong), thus one cannot modify a 3rd party directive in a 3rd party module without modifying the 3rd party source code.

Those limitations are good reason for anyone (I in this case) to suggest (potentially new) API changes in order to make AngularJS more powerful. That being said, my suggestion doesn't need to be specifically accepted, but some API change should be made in lieu of the fact that what I want to do is limited within the scope of AngularJS.

the modifications you are proposing have many side-effects.

Doesn't everything one does in programming have side-effects? Side-effects are not always bad. Can you elaborate on the bad side-effects that my proposed API would create?

The API I've proposed can have the following few rules associated with it (as does every API in Angular). I will refer to directives being attached to elements of another directive as "attached-directives" and the directive who's elements are having attached-directives attached the "other-directive".

1. The attachDirective method works on any other-directive that one is using in the module where attachDirective is called (even if it's a 3rd party directive defined in a 3rd party module).
2. When applying attached-directives to elements of other-directive, if those elements already have a directive with the same name as the attached-directive, then the attached-directive overrides the already-existing directives. Sure, this can change (even break) the way the other directive works (a bad side effect that can also be experienced with decorators). To prevent directives on elements of other-directive from being overridden, I can easily decorate my attached-directive so that it has different name before applying it to the elements of other-directive. That's no problem. The replacement of directives by attached-directives should happen before $compileation. Attached-directives also override directives of the matched elements in templates that get loaded by the other-diretive at any point in the future, before those templates are $compiled.
3. The attached-directives behave 100% exactly as they would had they been applied directly to HTML by hand. The only difference is that the call to attachDirective allows attached-directives to be attached programmatically when access to the HTML is not available, and when the directive isn't your own to modify.

Cases where attachDirective is used will likely differ greatly from cases where $provide.decorator is used. My aim is not to 'extend' another directive in the complex ways that can be done with decorator. I simply want to apply directives to certain elements out of my control. This is a simple use case that merits a simple API. Developers coming from a jQuery background will undoubtedly like this API. The API is not fundamentally changing how AngularJS works, it's simply allowing a new way to attach directives to elements. The result is exactly the same as applying directives manually to HTML elements in cases where the HTML is available.

The need exists, and an API that does like what I'm proposing would be powerful.

• Some way to conditionally apply directives #5524
• http://stackoverflow.com/questions/15279244/dynamically-add-directives-on-angularjs
• http://stackoverflow.com/questions/13459705/dynamically-adding-angularjs-directives
• http://stackoverflow.com/questions/16184557/how-to-dynamically-add-a-custom-directive-to-a-div-element
• http://stackoverflow.com/questions/16656735/insert-directive-programatically-angular
• https://groups.google.com/forum/#!msg/angular/an9QpzqIYiM/r8v-3W1X5vcJ

To conclude, one thing is clear about AngularJS: the use of already-made directives in HTML makes it so simple to do powerful things (e.g. like using ngModel on an input element to create a search filter). It is only easy to add directives to elements when the HTML is available for direct editing (but needlessly complex when the elements aren't available (which inevitably happens sometimes! (especially with 3rd party modules!))). Extending the ability to attach directives to an element of another directive in my proposed API is a simple extension of that powerful ability that AngularJS gives without the complexity of $provide.decorator. Even if decorator worked with 3rd party modules, having to use decorator is overly complex for the use case that makes people initially love AngularJS (applying directives directly to HTML to enabled powerful behaviors).

Do you (anyone reading this) have any other suggestions on how to simply apply directives onto HTML elements when access to 3rd party source code containing the HTML is not available? Also, do you have any suggestions on further improving and/or modifying and/or why not implementing my proposed API?

Thanks!