The solution can be optimized to stop searching, as soon as there was a node with alpinejs - and limit the depth.

const cloneAlpineJSData: (from: HTMLElement, to: HTMLElement, depth: number) => void = (from, to, depth) => {
  if (!window.Alpine || !from || !to || depth > 2) return

  if (from._x_dataStack) return window.Alpine.clone(from, to)

  for (let index = 0; index < to.children.length; index++) {
    const from2 = from.children[index]
    const to2 = to.children[index]

    if (from2 instanceof HTMLElement && to2 instanceof HTMLElement) {
      cloneAlpineJSData(from2, to2, depth++)
    }
  }
}

Hmm, I’m seeing some unexpected behavior when I switched from the non-recursive to this suggested recursive integration. It seems to be breaking reactivity within a LiveComponent when nesting AlpineJS components.

To illustrate, the following with the recursive integration works as expected and both the button and span’s text accurately reflect the boolean state of editMode in the parent x-data as it is toggled/updated by clicking the button.

<div x-data="{editMode: false}">
  <button x-on:click="editMode = !editMode" x-text="editMode ? 'Editing' : 'Edit'"></button>
  <span x-text="editMode"></span>
</div>

But by introducing an x-data declaration to the span, the span suddenly loses reactivity and the span text remains unchanged at false even when the parent state successfully updates as evidenced by the continued reactivity of the button text.

<div x-data="{editMode: false}">
  <button x-on:click="editMode = !editMode" x-text="editMode ? 'Editing' : 'Edit'"></button>
  <span x-data="{}" x-text="editMode"></span>
</div>

And if I switch back to the non-recursive integration, the span regains reactivity and the span text begins reacting again to the parent state. Still investigating, but any ideas what’s going on?

Did you use the second version, which stops after finding the first element with Alpinejs?

Alpinejs.clone initializes nested elements, if present at the root.

A month later, I must say if you run into this issue like this, you probably fell too much in love with Alpinejs (I did) and you will have more and more issues and poor performance for complex and bigger elements.

We ported now everything over to LiveView.JS, added all the missing functionality (push_js, hooks, eventListeners and so on) our self and ditched Alpinejs completely.

Definitely worth it! Would strongly suggest it.

To me, the big problem with liveview is missing a source of truth to UI behavior. It’s very frustraing to choose working with ui state in server state. When disconnection occurs, all data is cleaned, or you have to implement a very complex way to mantain state.

An alternative solution is to implement UI state with bare Javascript. And, it’s so annoying when you already used client side framework/libraries like React/Angular. For me, LiveView is not a tool for everything. Complex javascript UI’s needs, it’s better using phoenix only to build API

Alpine.js works great for me, except that v3 does not update data immediately when it is changed in the x-data “constructor”. v2 did not have this problem, which made it better as a “source of truth”. Now, data needs to be changed twice before the old change is detected. There’s some sort of lag in the code that detects when the values in x-data are updated. (Could easily just push the changes twice and keep some useless timestamp in the data so the code would update probably. Hacky and dumb, but would probably work.)

I also did not notice a difference with the recursive onBeforeElUpdated setting. Maybe I just didn’t make complicated-enough components to notice a difference. ¯\_(ツ)_/¯

Just in case this helps… I was playing with Alpine again and found a way around a few issues I had previously had with something similar.

Instead of having variables inside x-data, use an attribute and a mutation observer.

<div x-data="{foo: null}" foo={@foo} />

init() {
  this.foo = this.$el.getAttribute("foo");

  this.observer = new MutationObserver((mutations) => {
    mutations.forEach((m) => {
      if (m.attributeName == "foo") {
        this.foo = this.$el.getAttribute("foo");
      }
    });
  });

  this.observer.observe(this.$el, { attributes: true });
}

What is the definition of the persistAttributes function? I am having super strange Alpine behaviour inside a live_component.

Thank you!

This function is not relevant. It just persisted other attributes, that otherwise would have been overwritten.

i experienced issues with alpinejs 3.14.4.:
alpinejs components added via liveview don’t initialize anymore.

i pinned my alpinejs version to 3.14.3 for that reason

if anyone else stumbles upon this, let me know.