Closed dmarcos closed 7 years ago
setAttribute
, it would do getAttribute
to figure out what changed. For the obj-model component, that was returning a parsed/deserialized object. Since the obj-model uses the src
type, it breaks because the src
type does not produce the same value when called twice in a row. So a PR should fix that.setEntityAttribute
from the setAttribute
since attributeChangedCallback
is called anways, but in the case we do like setAttribute('material', 'color', 'red')
, we need to call setEntityAttribute
with some processed data. So, yeah we need to refactor somehow.By the way, how do I go confirm that attributeChangedCallback
is in fact getting called synchronously? Using setTimeout
?
I use the debugger. If attributeChangedCallback is called before the line below then it means is synchronous:
https://github.com/aframevr/aframe/blob/dev/src/core/a-entity.js#L479
Have y'all thought about switching to the webcomponents.js custom elements polyfill? (filed as #567.) perhaps just try it first.
setEntityAttribute
now no longer called in setAttribute
We're hitting some issues with multiple calls to
setEntityAttribute
on a single call tosetAttribute
. There are two separate problems:attributeChangedCallback
is always called. The native implementation in Chrome doesn't have this problem. A PR into the register-element polyfill to invokeHTMLElement.getAttribute
instead of our wrappedgetAttribute
might be the clean solution. There's no downside for them and it will make the polyfill more robust.attributeChangedCallback
behaves synchronously and when a component data changes we callsetEntityAttribute
twice. First in theattributeChangedCallback
and later in oursetAttribute
wrapper. We need to find a way to avoid redundant calls.@ngokevin thoughs?