Alpine component not reinitialized when DOM element is updated by LiveView in Phoenix framework

[jmsaugar]

Hello,

I am using Alpine with Phoenix framework v1.7.0 and I am having an issue with the reinitialization of Alpine components when Phoenix LiveView updates the DOM element of the Alpine component:

<div x-data={"{value: '#{@value}'}"}>
  <p x-text="value" />
</div>

As you can see in the code above, we define an Alpine component with a value that comes interpolated into the template by a render of Phoenix LiveView. After the first render, the component correctly shows the value, but if the LiveView updates the @value in the backend, triggering a rerender of the template, the Alpine component doesn't reinitialize and show the new value.

This issue is happening on Alpine v3.13.5, v3.13.7 and onwards, including latest v3.13.10
It does NOT happen on Alpine v.3.13.6

Interesting to mention that if we add an id attribute to the Alpine component element, it will behave like this:

• If the id is a fixed value, it will work as expected (reinitialize the component and render the new value)
• If the id value is tied to the interpolated value (like id={"#{@value}"}), it will NOT rerender the new value.

I have been reading through some of the changes of those releases and their PRs and I see there are some fixes that change this back and forth between those versions, but at this point I am not sure if this is indeed expected behaviour or a bug. Would please you confirm if this is the case? Thanks very much in advance.

[SimoTod]

The fix for livewire attempted in that realease was breaking a lot of other features/integrations used by a wider audience. As far as I know.

I suspect this should probably be addressed in livewire or with a third plugin if possible.

[krilllind]

I'm also curious, is there any difference between the different ways you initialise AlpineJS and how the reinitialisation works?
For example, this is what I personally would assume should happen:

<!-- This is only initialised once -->
<div x-data></div>

<!-- As long as value of prop `a` never changes, this should be stable -->
<div x-data="{a: 123}"></div>

<!-- This Phoenix specific example I would assume alpine to not be reinitialised, and instead only for the property value to change. -->
<div x-data={"{a: #{@my_variable}}"}></div>

<!-- This is only initialised once -->
<div x-data="myCustomComponent"></div>

<!-- This Phoenix specific example I would assume the alpine component would be reinitialised when variable changes -->
<div x-data={"myCustomComponent(#{@my_variable})"}></div>

Does this make sense or am I thinking incorrectly?
(This is still not the behaviour mentioned by OP)

[SimoTod]

it depends on how Phoenix does the mutation. None of them should re-init alpine but if it's just changing the x-data value, Alpine won't really see the change. After alpine starts, the state of the component is held somewhere else, the content of x-data doesn't matter anymore (it wasn't like that in some really old versions of alpine).

[jmsaugar]

the content of x-data doesn't matter anymore (it wasn't like that in some really old versions of alpine).

Probably that's the issue we are facing now. The way we understood it is that the Alpine client state would be destroyed and reinitialized if the DOM element was rerendered. If we didn't want this to happen, we could always prevent rerenders on this element indicating it to Phoenix (using phx-update="ignore" binding). But if that client state preservation is supposed to be the default behaviour, it is a breaking change for us.

[ekwoka]

It depends on how rerendering happens.

If it's swapping the elements, or if it's modifying the elements in place.

[ekwoka]

How does live view mutate the dom?