1

To my understanding, setting terminal to true will result in that directive being executed last, and any directives with a greater priority will execute before it (naturally), and any directive with a lower priority will not execute at all.

However, when using a custom directive with a built-in directive, it seems that this behavior is switched. Let's say we use a custom directive with ng-repeat, unless the custom directive has a priority of less than 1000 (which is ng-repeat's priority), it will NOT execute.

here is a JSFiddle representing my question: http://jsfiddle.net/codef0rmer/aNCY3/

In reference to the JSFiddle code, with custom-directives only(first, second): As long as first has a priority of 2 or higher, it will execute before second. If it has a priority higher than 2, it will not execute.

With custom-directives in conjunction with a built-in directive (noEntry, ngRepeat): Since ngRepeat has a priority of 1000, if noEntry has a priority of 1000 or higher, it will NOT execute, however, it will execute with a lower priority than 1000.

JHP
  • 23
  • 7

1 Answers1

2

I did some snooping in my fork of your fiddle, and I found that when the custom directive has a higher priority, it is executed before ng-repeat. In other words, it's executed before the li is actually rendered in the DOM. Since there's no list item to append, nothing happens.

You can see that the directive executes by adding a console.log statement before the return in your directive and opening the console on your browser, as I've done here:

App.directive('noEntry', function() {
    console.log("Testing...");
    return {
        restrict: 'A',
        priority: 1001,
        link: function(scope, element, attrs) {
            element.append('No Entry: Executed ');
        }        
    };
});

Playing around with the terminal declaration in second, I don't see any effect on no-entry.

Austin Mullins
  • 7,307
  • 2
  • 33
  • 48
  • That's a good point. That makes sense - so when I give it a higher priority, it actually does execute but since it executes before ngRepeat, it just isn't visible, but It still doesn't make sense to me why when no-entry is given a lower priority it still runs at all? If ng-repeat has a higher priority and is terminal, shouldn't any lower priority directives fail to execute? – JHP Dec 18 '13 at 19:13
  • Also the terminal declaration in second wouldn't have an effect on noEntry because first and second are in a different element. But see how when second has a higher priority of 2 and terminal: true, and first has a lower priority of 1, first does not execute. – JHP Dec 18 '13 at 19:15
  • @JHP I don't know what the intention is, but here are two other questions that address the subject: [Why Use Terminal?](http://stackoverflow.com/questions/18969610/why-use-terminal-true-instead-of-removing-lower-priority-directives), [How to Understand Terminal](http://stackoverflow.com/questions/15266840/how-to-understand-the-terminal-of-directive) – Austin Mullins Dec 18 '13 at 22:13
  • 1
    Ok, so my thinking right now is that the `terminal` setting on `ngRepeat` only applies to the HTML element being evaluated in place. In other words, it makes sure all other directives on the element will only apply to the child elements generated and not to the generator itself. – Austin Mullins Dec 18 '13 at 22:18