When do I need to call skipDuringClone()?

[bennadel]

I'm seeing in some of the directive patterns that DOM manipulation follows this pattern:

mutateDom(
	() => {

		el.after( clone );

		skipDuringClone(
			() => {
				initTree( clone );
			}
		)();

	}
);

However, in some personal experimentation, things seem to work if I get rid of the skipDuringClone() call and just call initTree() immediately. As in:

mutateDom(
	() => {

		el.after( clone );
		initTree( clone );

	}
);

I've tried searching Google, the forums, and the Definitely Typed .d.ts file, and nothing is really giving me a hint as to what the skipDuringClone() method is doing. Any input would be appreciated! I don't want to leave it out and be causing subtle bugs.

[ekwoka]

So some directives, declare themselves as being skippable in clone contexts, because of how cloning itself has already handled certain things the directive does.

skipDuringClone causes those directives to not initialize/do the things that are already handled by cloning.

I think it's only one or two directives that need this.

I think x-data is a main one for this.

Since cloning will have copied the exact current state of the element. If you reevaluate x-data you'd reset the data and end up with an extra stack.

[bennadel]

@ekwoka ah, ok. So, unless I have a very specific reason to do that, I can just skip (no pun intended) calling this method.

That said, it seems that all of the structural directives do make use of the mutateDom() and initTree() methods. I'll take this as a best practice then, to use internally when I need to add / remove DOM node within a directive.

Case-in-point, I'm working on a directive that clones a template reference and renders it in an arbitrary position in the DOM. So, given a template like:

<template x-ref="source">...</template>

I want to be able to render it anywhere with a given data binding using my x-template-outlet directive:

<template x-template-outlet="$refs.source" x-data="{ foo:"bar" }"></template>

This directive does several things:

1. Clones the source template.
2. Attaches scope to the clone.
3. Inserts the clone into the DOM.
4. Removes the "hook" template (the one with x-template-outlet.

So, I will wrap the actual DOM-insertion points in the mutateDom(). The tricky one is actually removing the "hook" template. If I remove that inside the mutateDom(), I see that the cleanup() callback is never fired. So, maybe I need to do the insertion inside the mutateDom() and the removal outside of the mutateDom().

Anyway, I'm still trying to get my head wrapped around the life-cycle stuff. Thanks!

[ekwoka]

Right, yeah I got it mixed up a bit.

since cloning the tree would create those elements that x-for would create, you want to prevent it from initializing x-for again and doubling the elements.

for example.

if you're only mutating a node, it likely won't cause any issues. If you're adding nodes, it might.

mutateDom basically turns off the mutation observer, does your changes, then turns it back on.

This can help ensure that you can control the flow of the initialization of the directives and trees.

So for adding, you might mutateDom( add elements) then initree. For removing, you can do mutateDom ( remove elements) and then destroyTree.

Or rather, destroyTree first?

idk. You destroy the tree to manually cleanup the tree. synchronously.

[bennadel]

Oh fantastic! I didn't realize there was a destroyTree() method. It doesn't seem that anyone has to use it (searching the Alpine code) - but I guess I have an unusual edge-case in that I have a directive that is both adding and removing nodes in a single action :) But, this makes me feel much better - that I'm not going to let some memory leak accidentally happen by not cleaning-up a node.

I'm updating my DOM i/o code to look this:

// Swap the template-outlet element with the hook and clone.
// --
// NOTE: Doing this inside the mutateDom() method will pause Alpine's internal
// MutationObserver, which allows us to perform DOM manipulation without
// triggering actions in the framework. Then, we can call initTree() and
// destroyTree() to have explicitly setup and teardowm DOM node bindings.
Alpine.mutateDom(
	function pauseMutationObserver() {

		element.after( domHook );
		domHook.after( clone );
		Alpine.initTree( clone ); // Setup the one I just added.

		element.remove();
		Alpine.destroyTree( element ); // Teardown the one I just removed.

	}
);

[ekwoka]

Yes, normally the mutation observer sees and destroys the trees.

I'm going to be submitting a PR to proactively do this with x-for and x-if removals, since sometimes they can lead to desync issues.

[bennadel]

Very nice :)

[bennadel]

As an aside, if anyone gets here and is curious to see more about the recursive template rendering, here's a write-up:

https://www.bennadel.com/blog/4603-recursive-template-rendering-in-alpine-js-3-13-5.htm