X-html in x-for

[SimoTod]

Currently, for newly created elements, the initTree callback is inside a mutate dom call which means that directives injected by x-html are not picked up by the mutation observer. It shouldn't be a big issue to move initTree outside of mutateDOm as we do for refreshScope when dealing with elements that are shuffled around.

[leobm]

ok , cool, the fix looks really simple. What are the implications of the fix? Why was the init for cloned nodes previously in mutateDom?

[SimoTod]

From my tests, it doesn't seem to have any undesired side effects. I don't know if there is a reason why it was built that way but Caleb will know when it gets time to review it.

[calebporzio]

Thanks @SimoTod!

Yeah I don't remember why I have it in there. I'm sure there was a reason. Hopefully the reason was just to make x-for faster because it's DOM Manipulations wouldn't hit the mutation observer. But I don't actually recall.

Because this could have other implications, or at least slow it down a little bit, is it a better strategy to instead call "mutateDom" inside x-html? and init the tree directly from there?

[SimoTod]

Thanks for the feedback, sounds good to me. I'll update the PR.

[calebporzio]

Thanks @SimoTod! I'm much more comfortable merging this. Thanks again