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!

[lgalfaso]

Hi, Let me comment inline

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.

A lot can be abstracted into a third party library, and I think that would be a good place for it. Not in the core.

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.

Documentation can be improved, but for sure that is not a reason to increase the API

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.

This works one way or the other. In both cases you need to know something about the third party directive, if this is a few or a lot, thats another issue

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.

Not true, you can decorate anything the $injector has access to

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?

Adding a way to reference DOM elements without putting super strict rules is a bad idea. Angular is trying to solve this by forcing you to have to be really explicitly on what you want to modify. When you say that you want to make a reference an element, then there must be a way to reference this element. Once that door is open, then there is no way to close it and sooner rather than later jqLite would need to implement everything jQuery is able to reference (or add a dependency on jQuery. Now, when there are members in the core team that think that even exposing jqLite was a mistake, then there are two opposite approaches. Angular is not moving you are proposing. A second, and not for that less important, is that there will be many rules that will need to be defined. How is this new API going to work when mixed with transclude? If there is an API to add new directives to a DOM element, should there be an API to remove them? Is the third party library able to handle this? Should it? It you expect third party libraries to understand all possible manipulations, then you are putting a huge burden on the this library.

Now that it looks like you understand the many issues involved and that you read quite a few on the problems, please re-read #6950 (comment)

[trusktr]

@lgalfaso I've been thinking about this again, being on another Angular project. I think this would be very powerful, especially when using 3rd party libraries who's code bases you don't want to touch. When you attach a directive onto child elements, it'd behave exactly as if those directives existed on the element before that element was compiled, as if the directive was in the markup of that library.

For example, if you know you're using some library that provides <awesome-directive> you could do

// add a directive to children that match a certain directive using the D: prefix
app.attachDirective('D:awesomeDirective', 'myDirective');

// add a directive to children that match a certain selector using the S: prefix
app.attachDirective('S:#header.dropdown', 'myDirective');

This would come in so much handy. I know that as owners of our code bases we can avoid this, but when using third party libraries we don't decide on the architecture for those libraries, so a feature like this would be powerful.

[lgalfaso]

@trusktr I think that most of what you are asking for, can be done with a third party library without any modification to angular core. The only reason I bring this up is that I doubt that something like this would ever be part of the core. Once you think that an external module works the way the author intended it to work, then allowing into the core a way to do general monkey patching is a big no

[trusktr]

@lgalfaso If this feature can be added through a 3rd-party addon that's be nice. If I get some time for it I'll try and see what I can do.

This feature isn't necessarily for monkey patching. Suppose you install some awesome 3rd-party calendar module. The calendar might generate a grid of <div> tags to create the calendar views. Suppose you want to add an icon at the top left of certain days. A directive might be the cleanest way to do it while staying inside the Angular paradigm. It's more like an addition than a monkey patch. Your directive would be made by you so you'd have the power of knowing what parent scopes you're using, which can be advantageous--the 3rd party directives have no idea.

Maybe I just don't have enough experience with Angular yet. What other way would you imagine doing something like this (i.e. directions to take on making a 3rd party plugin to achieve this functionality)?

[mustaphakd]

I'll be interested in knowing the proper path to take for such implementation.

[trusktr]

@mustaphakd Angular 2.x will be out soon. Instead of directives, there's components. Each component gets attached to a DOM element based on it's CSS selector. It might then be easy to attach components to the inner workings of a 3rd party component simply by making a new component instance in JavaScript who's selector simply matches that of something inside the 3rd party component.

I got to see @davideast's presentation on Angular 2.0.

David, do you think what I just described will be possible, attaching components to things inside a 3rd party component via selectors? This is basically what this whole issue was about, but seemingly difficult to implement compared to the Angular 2.0 components if selectors work as I'm imagining here.

If this will be possible in 2.0, I imagine that there could be 3rd party components that cause problems with each other if they use generic or similar selectors. Is this true?

For example, suppose I have <foo> elements in my page, and I am using a 3rd party component who's selector is "foo" and this component adds/replaces the content from it's template property into every <foo>. Suppose the foo component's template has an element <bar> in it. Now, if I load another 3rd party component who's selector is "bar", will this new component affect all of the <bar> elements that were inserted/replaced into all the <foo> elements by the first component?

[trusktr]

Or will shadow dom (or something) prevent this sort of thing, and in that case, will there not be a way to apply a component to elements of another (3rd party) component (who's code we wish not to modify)?

A practical use case would be adding a special functionality to all images in a page, even if they are in a 3rd party component, without having to modify the 3rd party component.

[gkalpak]

I really don't get why there is this long discussion around this.

As @lgalfaso already mentioned, it is very possible and easy to implement it with Angular 1.x (e.g. implementing another directive with the same name, higher priority and manipulate its content in a postLink function).
Further more, it's super easy to wrap this functionality into a helper function or even a module and use it in any app you want.

(Bonus-points for naming your helper/module "attachDirective" and being super-happy 😛)

[mustaphakd]

@gkalpak can U imagine efficient memory utilization? angularJs already does an excellent job clearing views out of memory when we tell it to do so, but currently all controller are preloaded into memory when the script is run and once initialized, their instance stays. currently, we have to plumb some infrastructural codes to properly remove instances from memory or reload them on demand.

[gkalpak]

@mustaphakd: This sounds like a totally different issue. If you have found a memory leak in Angular core, you should definitely submit a new issue (providing all the necessary details and (if possible) a live reproduction (e.g. using JSFiddle, Plnkr etc)), so the Angular team can look into it.

[mustaphakd]

@gkalpak U misunderstood me. I have not found any memory leak in Angular core. although the title is specifically about directive, I was also mirroring the same concept to views being loaded on demand with their controller cleared from memory once the view is disposed off. may be U right both ideas may not even be that parallel at the moment.

[gkalpak]

@mustaphakd: Sorry, I lost you. Is it a question ? If so, you should direct it to the appropriate channels to get help ;)

[mustaphakd]

@gkalpak: no, it was not a question. it is just another current issue we find ourselves confronted with: loading and appending new directive to element being tied to an existing directive; loading and appending new controller to an existing element (not so much of an issue since there are easy work around thanks to the api) but clearing the component from memory once done using it demands great care unless we instantiate the component on a property that is globally accessible. angularJs seems to do a great job clearing views from memory but not their controllers. So a request here would, loading and removing components from memory (including their js scripting logic).

[gkalpak]

@mustaphakd: It's still not clear to me what "removing components from memory" means.
In Angular 1.x there is (still) no concept of "components", but it will be handled in Angulr 2.x.

[mustaphakd]

@gkalpak : well, can we think of directive and controller as such?

[schmod]

Components/directives are "loaded into memory" as soon as the page loads the script file.

An instance of a directive is typically tied to its DOM element and/or Scope. When the element is destroyed, Angular tries to remove all references to the Scope. When all references to the former element and its scope have been cleaned up, the garbage-collector can remove it from memory.

Apart from that, there's not a whole lot of memory management that goes on, given that JavaScript apps have no control over the GC.

Moving back to the original issue: Interrupting the directive compilation cycle can be computationally-expensive, and have unpredictable side-effects. If you absolutely need to do it, you can add a new attribute to your element, and re-$compile it.

[gkalpak]

@schmod: There is no need to "interrupt the directive compilation cycle"...

[mike-marcacci]

Hey all, back to @trusktr's proposal, I think this would be extremely useful and quite easy to implement. I think the only constraint would be that a programmatically-added directive would need a lower priority than the directive that added it.

For anyone else who stumbles across this issue and just needs the functionality today, there's a clever post on SO that will get you up and running right now.

[davincho]

+1 Definitely would be really helpful if adding directives programatically is supported.
In my case I wanted to reuse the functionality of ui-keypress in my own directive (behavioral directive without template)

[mikehaas763]

+1. In my case I have a dashboard that can have say about a dozen "component" directives on it at any given time. They are in a gridster like grid where the components can be resized, moved around, added from a list and removed. However the list of components that can be added is in the hundreds. Don't wanna have to set up a ng-switch for that :)

[murli2308]

In my case. I have dashboard and list of component (directives), User can select the components from list of component for Data Visualization. I need a way to dynamically add and remove the directives. It will be a great help.