Changing x-data attribute value on an existing element does not update Alpine's internal state

[MichaelWest22]

Description

When an element's x-data attribute is updated in-place (e.g. via htmx morph), Alpine does not apply the new data scope. The element retains its old state instead of reinitializing with the new x-data value.

Root Cause

Once an element is initialized by Alpine, _x_marker is set on it. When x-data is changed, Alpine's mutation observer treats this as a remove + add of the attribute and calls the x-data cleanup function. However, this cleanup does not clear _x_marker or other internal Alpine state properties. When Alpine then detects the attribute being "added", it sees _x_marker and skips initialization, leaving the element with its old data scope.

Steps to Reproduce

1. Render an element with x-data="{ count: 1 }"
2. Use htmx morph (or any in-place DOM update) to change the attribute to x-data="{ count: 99 }"
3. Observe that Alpine still reflects count: 1

Expected: Alpine reinitializes the element with the new x-data value.

Actual: Alpine retains the old data scope because _x_marker blocks reinitialization.

Possible Solutions

1. External workaround (htmx extension): Detect x-data attribute changes after morph completes and manually call Alpine.destroyTree() + Alpine.initTree() on the affected element.

2. onAttributeChanged hook: Add a mutation handler inside Alpine that detects x-data attribute changes and triggers a full de-init/re-init cycle. (branch)

3. Fix the x-data cleanup function: Update the existing cleanup to perform a full teardown of the element and its children (clearing _x_marker and related state), then call initTree to reinitialize. (branch)

[ekwoka]

This is mostly intended, since it's impossible for Alpine to really know what values you would want to update, and which you might want to stay the same (like if some changed at runtime?)

The whole idea of morph is that you're preserving the state of the components.

If this is to be supported, I think none of those solutions (that are in Alpine's control) would be appropriate.

The idea would be to just evaluate the x-data and apply it's data onto the existing state.

[MichaelWest22]

yeah handling runtime changes is a tricky issue. But i think with the setAttribute and morph case we should ideally be respecting the changes performed by the server where possible. Handling all the edge cases well is not trivial. I think if a x-data key changes in a server request we should respect that and update the client runtime value even if it has been changed locally. But then you get issues that it could also clobber unchanged data keys as well we may need to avoid.

main...MichaelWest22:alpine:x-data-attribute-change4

Did some additional testing to test these situations and here is another possible solution. But it has to track the original values to prevent updating things that have not been changed. And handling the attribute removal case instead of just the change one turns out to need a different code path it seems.

[ekwoka]

Just what if the data key is changing because of client state updates?

Like imagine a product list page, with filters.

Where the x-data might be injecting initial states.

But changing the filters causes the morph (and you may need some filters to change in ways the client can't know so you morph the filter area too), but the filters are already aware of the current state, since they just created it.

Now just basically Object.assign'ing the new data result onto the old one would still work here, without reinitializing everything, but could harm cases where you use watch/effect to trigger updates...

[MichaelWest22]

Yeah we probably need to deal with client state updates which is why I've been testing this using originalValues object so it can be smart about updating the state data. If we just object assign all the keys from he new data all values will get updated even if the server did not request an explicit update. The idea is that if the server requests a data key change from its previous value via a morph we should respect that but if there is a filters key that is only updated locally and we don't want it changing the server would need to keep sending filters with the same initial default value every time.

One potential issue is if you submit a server request to update the list that passes up to the server the current filter value and this returns a result which we morph in a second later after the response comes back and the server renders the updated filter value in the response it will override the filter value that could possibly be changed locally in the last second. But this edge case seems unlikely to be a real world issue to me and this is how many non morph based updates already work.

Also note I was trying to see if I could solve all the edge cases in the above test branches but maybe some of the cases I was handling are not really important. If we ignore the case where a x-data attribute is removed from an existing element, which to me seems like a very unlikely edge case, we could just deal with assigning the new server changed values in the attribute change case which makes the change much simpler.

main...MichaelWest22:alpine:x-data-attribute-change5

[ekwoka]

Updates to filters changing while the server is responding is actually a more likely case than you'd expect. When I didn't use morph, this would occur regularly if you just did full swapping.

Or think a cart quantity thing.

You want to respond to quantity changes, but not reset them, and people can easily click those faster than the server would respond (and slower than a reasonable debounce)

[MichaelWest22]

Yeah it is real tricky if you try updating x-data client side and server side at the same time! Most of the time you would only want to consider updating a key either all client side or all server side and my proposed idea works really well here as you can choose when to modify or leave as default existing x-data values.

But for your cart quantity example they may want to update in both places causing problems. The current Alpine code is a bit broken in this case right now as when you modify the quantity from 1 to 2 client side and then also morph in quantity = 2 from a server response it will update the x-data attribute from 1 to 2 and trigger the cleanup which removes the reactive data from the elt._x_dataStack and then adds back a new copy with qty=2 as new reactiveData object. But all the child elements are left still referencing the old dataStack reactive data which will appare to be the real reactive local state but the root element will actually have a new sperate dataStack value. Any new child DOM nodes added will actually link to the new orphaned dataStack value which is confusing.

You could probably add a couple of lines to handle this situation better like:

// In cleanup:
if (el.isConnected && el.hasAttribute(prefix('data'))) return

// In main x-data directive init to prevent it doing init twice:
if (el._x_dataStack) return

Then x-data updates would be blocked properly with no wierd impacts.

[MichaelWest22]

This has now been resolved in #4868 as this change now handles updating x-data attribute properly for livewire morphed changes and so will resolve htmx morph as well.