Investigate alternatives to MutationObserver for attributeChanged detection about three-elements

[hmans]

Here's a PR with a potential solution: #34

[benjamind]

I see @hmans has already raised this issue on the webcomponents WICG here

[hmans]

Hi @benjamind and thank you very much for opening this issue and going into so much detail.

That fact that three-elements is going through MutationObserver to mitigate the observedAttributes "issue" is definitely something that I'm not happy with, and needs to be addressed at some point. Right now, though, I simply don't have any data to work with; as you have already mentioned, it is something that needs to be measured and benchmarked in a larger project. (Luckily, I'm working on a larger project, so that will give me plenty of opportunity to do this!)

I've thought (quite a lot) about all the options you've described, plus one that's a bit crazy where, after inserting elements into the DOM, they immediately replace themselves with different, "upgraded" elements that have their observedAttributes set to the properties of the wrapped object. I'm confident it would work, but I believe the impact it would have on the overall approachability of the library would be catastrophic.

So, here's how I've been planning on tackling this:

In the long term, I'm hoping that there will either be improvements coming in a future version of the WebComponents spec (just being able to imperatively update observedAttributes, as I very naively suggested in the WICG discussion, would be a boon), or someone much smarter than myself will figure out a cool workaround. :-)

In the medium term, there are opportunities to allow authors of complex projects to selectively optimize this. I haven't spent any time documenting this, but three-elements already allows you to generate new tags backed by ThreeElement.for(constructor). We could allow users to pass a list of attributes there that will become the class' observedAttributes. When -- if -- users are seeing bottlenecks around the use of MutationObserver, they could use this to manually optimize things.

In the short term I'm actually relatively confident that this isn't going to be a big issue, for the simple reason that in most non-trivial projects, you will end up mutating the Three.js object directly instead of going through its element's attributes. This of course largely depends on the code architecture you're choosing and the framework you're coupling three-elements with, and at this point, we don't really know yet what patterns are going to emerge here, but just like in react-three-fiber, where you're advised to mutate the Three.js objects directly instead of changing props (and causing re-rendering of the component tree), a similar rule of thumb can be established here.

(Ironically, the way that I'm using three-elements in my big project heavily relies on changing elements' attributes, so if there is a problem, I will be among the first people to be hit by it; anyone reading this can rest assured that I will have enough reasons to stay on top of this topic. :D)