Proper AlpineJS Integration with Liveview

[Rubas]

Problem

When using more complex nested components, especially with live_components, AlpineJS can stop working after updates.

This issue is also documented here:

Adding new LiveView component ignores AlpineJS directives

Hello! I am having a weird issue when adding new LiveView components to the page. AlpineJS directives for component are totally ignored for the new component. Anyone else stumbled on this before? AlpineJS works as expected. I followed the guides from the forum to upgrade it from v2 to v3. My app has a form that allows user to add some data and that data added to the list on the page in the form of a new component. However, when the new component is added and rendered on the page its Alpine dire…

AlpineJS "loses" reactivity when rendered using <.live_component> Liveview >0.17

I have AlpineJS (v3) wired into a phoenix app. It has been working great so far. I recently started using Liveview in my app, and noticed that any x-show attribute is not reacting to state changes based on the component’s data. I have a calendar component I am trying to render from an events_live component, like so <.live_component module={MyAppWeb.EventLive.CalendarComponent} />. There is a dropdown menu that is suppose to toggle based on an open data attribute, very basic alpine stuff. It d…

Nested component is re-initialised when LiveView Assigns is updated

Source

All available documentation instructs you to integrate Alpinejs in the app.js within the onBeforeElUpdated hook like this.

// assets/js/app.js
let liveSocket = new LiveSocket("/live", Socket, {
  params: {_csrf_token: csrfToken},
  dom: {
    onBeforeElUpdated(from, to) {
      if (from._x_dataStack) {
        window.Alpine.clone(from, to)
      }
    }
  }
})

This doesn’t factor in that LV updates can be nested html elements!

Solution

You need to clone the Alpine data not only on the root element but also in all child elements .

Here is our solution.

// assets/ts/liveview.ts
const cloneAlpineJSData: (from: HTMLElement, to: HTMLElement) => void = (from, to) => {
  if (!window.Alpine || !from || !to) return

  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)
    }
  }

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

  // Set `x-persist="type,style.height,style.minHeight"` to prevent these attributes from being overrided by an LV update
  persistAttributes(from, to, from.getAttribute('x-persist'))
}

[...]

const liveSocket = new LiveSocket('/live', Socket, {
    hooks,
    params: { _csrf_token: csrfToken },
    dom: {
      onBeforeElUpdated(from, to) {
        cloneAlpineJSData(from, to)

        return true
      }
    }
  })

Note:
persistAttributes is an another helper which, persist certain attributes which are updated by Alpinejs. For example we have a <textarea> that changes style.height and style.minHeight depending on the entered data.

[Rubas]

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++)
    }
  }
}

[codeanpeace]

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?

[Rubas]

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.

[Rubas]

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.

[v1d3rm3]

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

[arcanemachine]

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.)

Difference with x-data from 2 to 3? · alpinejs/alpine · Discussion #3429

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. ¯\_(ツ)_/¯

[krishandley]

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 });
}

[niccusan]

@Rubas

persistAttributes

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

Thank you!

[Rubas]

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

[werkzeugh]

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.