Angular lacks support for recursive directives

[robstolarz]

This is a pretty major issue in terms of being able to do things "the Angular way."
My model is a tree. Trees require recursion. I'm making an app that depends on a directive that allows movement of nodes inside a tree. In order to be able to move nodes inside this tree, I need to place "drop zones" which will detect elements that are dropped onto them.
Unfortunately, with the "Angular way" of implementing this (2 is a JSFiddle that uses similar concepts; recursive directive with transcluded template for each node of the tree) the transcluded template is rendered totally unaware of where it is located relative to where its data comes from, because the transcluded template has to be removed from its parent element before compilation.
If it's removed, it loses its scope; if it's not removed, 3 happens. (Open a console, you'll see the infinite recursion. It's the same as 2 but with the compile function commented out.) Angular tries to compile the directive while it's already compiling the directive, which fails hopelessly.

Now, there are workarounds, which is why it is possible that angular-ui-tree 4 exists. However, the only way to use it is through a recursive template (5 is a good starting point) which misses out on all the cool directive support and parametrization and is generally not the intended use of templates. The implementation here becomes hairier than it needs to be because of the lack of support for recursive directives.

[Izhaki]

I've been writing tree directives in angular lately and you can pretty much do whatever you want, given you understand Angular well enough.

Anyhow, if I understand your issues correctly, I believe the following blog (Building Nested Recursive Directives in Angular) is demonstrating how to do exactly what you want. Make sure you also read the comments.

[caitp]

this is a valid issue, recursive templates are not really possible in angular without hacks currently. It's not that the hacks aren't possible, but they really, really suck, both in terms of code smell and performance, and should not be necessary.

Unfortunately, it's not a super simple problem to solve on top of the current compiler.

[robstolarz]

@Izhaki scope is not respected by the transcluded HTML in link 2 in my original post, which is the real thorn in my side... and I adamantly refuse to put my entire view template inside my tree directive :P

@caitp At least I know I'm not crazy... perhaps the compiler should check the current stack and see if it's recursively compiling a directive that it is already trying to compile? Then it would defer compilation..?

[caitp]

@caitp At least I know I'm not crazy... perhaps the compiler should check the current stack and see if it's recursively compiling a directive that it is already trying to compile? Then it would defer compilation..?

It's not quite that simple --- if we defer compilation, we need to have machinery for doing the compilation later, and it's not clear what would trigger that.

It could be element transclusion, since the most common use case for this would be ng-if or ng-repeat, but it's not a trivial problem on top of the current compiler. If this gets fixed, we need to fix it in a way that doesn't break the status quo of angular apps. It's complicated =(

[robstolarz]

@caitp what about adding a new rule to the compiler, like ng-recursive or something? Just tossing ideas out here.

[petebacondarwin]

@callmeStriking - I believe that your scope issue may be resolved in a later version of Angular - your link is to a fiddle that is using 1.2.0-rc2. We did some work recently on tightening up what scopes are passed to nested transclude directives.

[robstolarz]

@petebacondarwin Close, but no cigar. The failing case (3, on Plnkr) uses Angular 1.3.0-beta.5
Edit: unless there's a newer Angular than that and I've misunderstood something

Edit 2: Tried again. 1 After #, the local index of the element should be shown. Instead, I got nothin'. (Still 1.3.0-beta.5. Inside the link part of the compile function, I do have access to the scope but the elements will never be aware of that). Even if adjusting the scope did work, it still wouldn't fix the fact that this is a hack...

[jeme]

For reference: https://github.com/dotJEM/angular-tree

I know that that solution uses two directives, but that brings some advantages with it, and when we have accepted that, then what are we really missing?...

[robstolarz]

@jeme What advantages?

[jeme]

@callmeStriking In this case it's a common directive for all recursion, having the two seperates directives means you can embed recursions in recursions of different types.

Not that that may be a very common usecase, regardless of that I think the Syntax is elegant enough to be acceptable.

Obivously you can do that if you go and make a new recursive directive again, and again, and again with different names... but why should we do that if we can make one simple solution all can just use in their directive templates?

[robstolarz]

@jeme Why not be able to create your own, native recursion? Also, does your solution mangle the scope like above ones do?

[Izhaki]

@callmeStriking

Although this has nothing to do with Angular, I feel obliged to share my experience and suggest you are approaching this problem with the wrong strategy.

Indeed, most drag-and-drop (DnD) frameworks use 'drop zones', but if you really come to think of what should be the correct abstraction for the problem, you should distinguish between:

• Drop-in: that's the 'traditional' drop zone, where the drop target is a container. Users will drop into that container.
• Drop-in-between: where the user wishes to drop between two containers.

A tree (or a table) DnD is a classic drop-in-between. As such, instead of throwing more drop zones than tree nodes, you should define the whole tree as a single drop zone, and work out the 'above' and 'below' containers of the drop, then work out the legal drop positions based on that.

Lastly, do remember that users may want to drop below the last node, where, in theory at least, there can be as many drop positions as the levels of the last node (so if your illustration would only go as low as item E, users can drop below A, C and E). Implementing this type of drop will be substantially easier if the whole tree is the drop zone.

[robstolarz]

@Izhaki That makes quite a bit of sense, but: drop-in-between, in this case, can't be done using existing hacks because using them mangles the scope.

[Izhaki]

Is this plunk of any help?

It uses the contents of the tree directive as a template:

<tree ng-init="nodes = children">
  <ul>
    <li ng-repeat="node in nodes">{{node.label}}
        <children ng-if="node.children" ng-init="nodes = node.children"></children>
    </li>
  </ul>
</tree>

With the directives simply being:

.directive( 'tree', function() {

  return {
    restrict: 'E',

    compile: function( tElement ) {
      tElement.template = tElement.html();
      return function() {};
    },

    controller: function( $scope, $element ) {
      this.getTemplate = function() {
        return $element.template;
      }
    },
  }
})

.directive( 'children', ['$compile', function( $compile ) {
  return {
    require: '^tree',
    restrict: 'E',

    link: function( scope, element, attrs, treeCtrl ) {
      var iTemplate = treeCtrl.getTemplate();
      element.html( iTemplate );
      $compile( element.contents() )( scope );      
    }
  }
}])