Thanks. This solves the thread for me seeing as this is already a known limitation
nduitz
nduitz
My use case is a timeline I use in a game that is always rendered but only becomes interactable if it is the players turn.
Your suggestion would certainly work, but I went with updating the id for now. Thanks for your input though!
0
nduitz
Btw I think the exact behaviour I observed is documented in code here:
https://github.com/phoenixframework/phoenix_live_view/blob/e69816c8c094435f40d26ff1eb0ab4eb8b83d2b9/assets/js/phoenix_live_view/dom_patch.js#L233
// if we are patching the root target container and the id has changed, treat it as a new node
// by replacing the fromEl with the toEl, which ensures hooks are torn down and re-created
0
LostKobrakai
While this indeed the case it seems rather waistful to throw away a perfectly valid dom tree just to enable/disable interactivity.
1
felix-starman
Obviously this might not be something you want, or might make your code messier but could you conditionally sort based on a data attribute being set?
Or if it’s action based, you could conditionally set some data attribute to JS struct/call, and then on your phx- binding, use JS.exec to execute it
0
steffend
Phoenix Core Team
That change is specific to LiveComponents, it doesn’t affect regular DOM nodes. And it only makes the behavior consistent between LiveComponents and any other node when changing its ID.
0