LiveView - Element attributes not updating, but phx- attributes work fine

Hello,

I’ve recently been playing with LiveView and have hit a weird issue that I can’t find any documentation on. I’m attempting to update “non-standard” attributes on an element (i.e. position="0 0 0", rotation="1 0 0") but find that those attributes simply don’t update on render. If I prefix the attribute with phx-, i.e. phx-position, then the updates come in as expected. Unfortunately, I am working with a third-party library and need the properties without the phx- prefix.

Is there something like an attribute I can use to tell Phoenix/LiveView that those particular properties are dynamic and will (probably) need updating? Do I need to set up a hook which basically el.setAttribute('position', el.getAttribute('phx-position'))s?

Thank you for your help!

Not sure if I’m understanding correctly, but have you tried assigning the attribute values themselves to the socket? i.e. position="<%= @position %>"

Forgive me I was unclear! Here’s an example snippet:
<my-element position="<%= @pos %>" phx-position="<%= @pos%>"></my-element>

In this example, position does NOT update but phx-position DOES update. I’m not totally sure why one would update but not the other. Hope that is a bit more informative!

I tested this out and couldn’t reproduce it - have you tried using the master branch:

{:phoenix_live_view, github: “phoenixframework/phoenix_live_view”}

Ahh, of course. Something strange is happening in the 3rd-party lib which is not allowing the DOM to be updated on a handful of its tracked attributes.

I’m attempting to use A-Frame in conjunction with LiveView, but it seems like A-Frame does NOT play well with the dynamic updates. I was really hoping I just had the LV configured incorrectly.

I tested my code with a various number of properties and they all update as expected - except for the position/rotation attributes which are read (and apparently written to) by A-Frame. Bummer.

Sorry for the noise.

You may want to try calling A-Frame either in the mounted() or updated() function of a hook - I’ve had similar bumps with 3rd party libs and the solution was usually somewhere in there :slight_smile: