Transcluded directive is not rendered when said directive performs a tElement.replaceWith(...) in compile.

[TheLostBrain]

Good day.

This is essentially a re-opening of issue #1367 as the bug is still persisting as of Angular 1.2.22 (and 1.3.0-beta.18).

However, I'm also providing a plnkr with an extremely clear example of the issue and even a hacky workaround I ran across in the Angular google group.
http://plnkr.co/edit/KrNFVvPg7NiQco7A9xbn?p=preview

The original Issue and workarounds are further discussed...
here: #1367
and here: https://groups.google.com/forum/#!msg/angular/GI50hYNe2yQ/6ObjlKmB9qMJ

Would be awesome if one of our Angular rock stars could squash this one. ;)

[caitp]

what is the use case for using replaceWith in compile? just trying to avoid issues with attribute merging or something?

[caitp]

Anyways, there's no possible way you could ever expect this to work --- The element you're manipulating (the parent node of directive2) isn't really in the DOM, and changes to it doesn't matter --- only changes to the node itself really matter here --- even replacing tElement[0] with a different DOM node won't do it, because the jqLite version of the node doesn't really matter. We could change it so that it did matter, but it would potentially break people.

Even if we did make that change, replaceWith() still wouldn't do what you expect, because it wouldn't modify the $compileNode object --- we'd have no way to know that you replaced the original compileNode, or which node you replaced it with if you did.

[caitp]

What do you think @petebacondarwin / @IgorMinar --- is that a change we should make to the compiler? (to rely on the modified jqLite object rather than just keeping and using the reference to the original DOM node)

[TheLostBrain]

Thanks for the response caitp.

I've seen some other cases for it but for me I've been using it primarily to just completely blow away the original directive element and replace it with a much more complex set of html and directives.

In some cases I'll pick and choose some of the attributes (some of which may themselves be directives) from the original element and distribute them around to the other directives my current directive may be housing.

In that particular case it's a bit cleaner IMHO to just be able to blow away the original element. (In contrast to the standard behavior where new content is appended to the original element and the original attributes are left in place to possibly cause issue).

Of course it's always possible to be sure the API you expose doesn't make use of "real" attribute names... or to just go back and removeAttr them from the original element... but it would be easier if transclusion and tElement.replaceWith played nicely together. ;)

If it's not feasible or is going to break someone then by all means please skip it. Otherwise would love to see it.

Thanks for any efforts and the crazy fast response. :)

Really loving Angular and appreciate the hard work you and the rest of the team put into it.

[IgorMinar]

If you really need to replace the element then why not use replace: true directive option?

Replacing an element like this can cause many other issues, so I would highly discourage it unless you can't do stuff without replacement (e.g. when building svg components).

We really don't want people to replace elements like this, so we shouldn't try to fix it for one scenario because then we'll need to fix it for 10 other scenarios.

Sorry!

[TheLostBrain]

Hi Igor thanks for the response!

I would use replace: true but I thought it was being deprecated and removed?

From the latest documentation:
//////////
replace ([DEPRECATED!], will be removed in next major release)

specify where the template should be inserted. Defaults to false.

true - the template will replace the current element.
false - the template will replace the contents of the current element.
//////////

Got that from: https://code.angularjs.org/1.3.0-beta.11/docs/api/ng/service/$compile

Is it possible replace: true will be kept around then?

Thanks again.

[IgorMinar]

yes. the option is deprecated and shouldn't be used for pretty much the same reason, replacing elements like this works in some cases, but not in all. replace: true option however covers more situation, so that's why I suggested it.

there are some cases when element replacement is a necessity (like svg-templating) and we are looking into how to handle that scenario. until we have a solution for the corner-cases the replace: true option won't be removed. But again, use it only if you don't have another option.

[mlarcher]

What if you want the ng-include content to replace the node the directive is hooked onto ? Is it possible to achieve that without using replaceWith and without rewriting a custom ng-include ?

[TheLostBrain]

mlarcher: Unfortunately, I believe the point both caitp and IgorMinar are making is that we really shouldn't be replacing the original directive node as it's not prescribed Angular practice and could result in unexpected behavior (hence the directive not being rendered when transcluded, etc.).

As stated replace:true works (for now). However, I'm going to avoid both it and the replaceWith so as not to run into issues w/ porting to 1.3, etc.

A somewhat viable workaround (unless I'm told otherwise again) is to just go with the standard node-appending behavior (either inherently via using template/templateUrl or via tElement.append) and then just do tElement.removeAttr('...') for any problematic attrs.

Lastly, I have the feeling that having to jump through such hoops (node replacement / going back and removing attrs) is likely an indication that I'm making things more complicated than they need to be and can be avoided entirely with a little planning.

Alright then seems this one is definitely closed for good now.

Thanks for taking a look guys.