Issue with cloneNode with Phoenix LiveView

[FabienHenon]

Hi,

I'm trying to integrate Alpine into my Phoenix LiveView application.

I followed some instructions saying that I have to put this code:

let liveSocket = new LiveSocket("/live", Socket, {
  dom: {
    onBeforeElUpdated(from, to) {
      if (from._x_dataStack) {
        Alpine.clone(from, to);
      }
    },
  },
});

LiveView also uses Morph, so when an element is about to get updated, I have to call the Alpine.clone function to "restore" the Alpine state in the updated component.

It appears to do the job.
But the function is deprecated, and as I understood, cloneNode must be used instead.

That's what I did, but now, everything is broken.

I have a simple broken example:

<div x-data="{selectedTab: 'elements'}">
  <button
      class="menu-item"
      @click="selectedTab = 'elements'"
      x-bind:class="selectedTab == 'elements' && 'selected'"
    >Elements</button>
</div>

With the code above, the selectedTab receives the selected class.
The code works.
But when Phoenix LiveView updates the view, if I use cloneNode the selected class disapears.
While it is still here when I use clone.

I checked the code and they seem to do pretty much the same thing, so I don't understand why my button keeps its selected class when I use clone, but not when I use cloneNode.

For information, the button node, goes through the onBeforeElUpdated function, but because it does not have a _x_dataStack it is not cloned.
The div node containing the x-data also goes through the onBeforeElUpdated function and is cloned.

In both cases (with clone and cloneNode) the _x_dataStack is copied.
But with cloneNode the button does not have the selected class.

It's like if the x-bind:class didn't see any change in the state (which is true), and, thus, didn't update the classList.

This behavior seems logical, but I still can't figure out why it's not the same with clone.
Neither, how I can do to make it work properly.

Thank you for your help

FWIW: I also have elements in my page with custom directives and I could see that, with clone these directives are called again, but not cleaned up (surely because they are not really removed from the DOM, only updated).
And with cloneNode, these directives are not called again, but they are cleaned up and removed 😅
(These directives are on template nodes, and all of them inside loops with x-for)

EDIT

I think now I understand why clone gives me my selected class.
It's because of this code executed by clone:

export function cloneTree(el) {
    let hasRunThroughFirstEl = false

    let shallowWalker = (el, callback) => {
        walk(el, (el, skip) => {
            if (hasRunThroughFirstEl && isRoot(el)) return skip()

            hasRunThroughFirstEl = true

            callback(el, skip)
        })
    }

    initTree(el, shallowWalker)
}

The cloned element is the one with x-data, thus when the walker first run, hasRunThroughFirstEl is false, we continue.
Then, hasRunThroughFirstEl is true, but isRoot(el) is never true because they are children using the state, but not defining one.

So, clone executes initTree for the whole tree (until it encounters another node with a x-data attribute (which is not the case in my use case).
And cloneNode only executes initTree for the cloned node as this code shows:

initTree(to, (el, callback) => {
            // We're hijacking the "walker" so that we
            // only initialize the element we're cloning...
            callback(el, () => {})
        })

This seems intentional however, but it prevents me from keeping my selected class if the button node is updated by LiveView.

I think there are also other issues with clone when using templates and x-for loops.

EDIT 2

A change in the list of classes seems to trigger an attribute added event in the mutation observer.
So, I guess a directive could intercept this event (like for the cloneInterceptor), filter the attributes it is interested in, and updated its state accordingly.
The x-bind directive could do that to intercept changes in class, style, etc... attributes and update them with the current state.

I think this could solve a part of my issue with the selected class being removed when Phoenix LiveView updates its attached node.

But there is still the issue with loops deleting their content and not recreating it.

[FabienHenon]

I figured out what was the problem and I was able to fix it.

For the cloneNode issue, here is the code to use for phoenix LiveView:

dom: {
    onBeforeElUpdated(from, to) {
      if (from._x_marker) {
        Alpine.cloneNode(from, to);
      }
    },
  },

cloneNode is called on update for any element handled by Alpine. Not only root elements.
This way, children of a root element being updated will be initialized by Alpine (solves my class problem).

---

The other issue was with template nodes being updated (their created elements were being removed from the DOM).
The issue is actually not directly related to template nodes, but to the directives that create/clone elements (like x-for, x-if, x-teleport).
When liveView does a dom patch, from the point of view of Phoenix LiveView, these created/cloned elements are not part of the page (they are created by Alpine, not by LiveView).
Thus, when there is a dom patch in a parent node, morphdom removes them.

In my use case, I could simply solve this by surrounding my x-for and x-if directives with a div containing the phx-update="ignore" attribute.
This attribute tells LiveView to ignore what's inside that element. This way, it ignores the creation/clone of the elements by x-for and x-if.

I had another use case where I couldn't use phx-update="ignore".
To avoid having my created/cloned element removed from the DOM I had to create a custom directive and to use a MutationObserver to be notified if my created/cloned element was removed from the DOM, so that I could recreate it.
This is ugly but that's the only solution I've found so far.