- From: Hendrik Mans <notifications@github.com>
- Date: Sat, 16 Jan 2021 07:06:25 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/565/761578383@github.com>
I would like to add an example for a situation where I do not know the attributes my custom elements will expose in advance. I am writing a library called [three-elements](https://github.com/hmans/three-elements) that, at import time, walks through the exports of Three.js and dynamically defines a new custom element for every one that can be instantiated. When it encounters an attribute that also exists as a property on the wrapped Three.js object, setting this attribute will also set that object's property. Unless I'm missing something terribly obvious, there is no way to implement this using `observedAttributes` -- maybe except for hand-crafting each element, or keeping a list of Three.js object properties somewhere, but this library aims at working with any version of Three.js -- which is a big selling point for places that, for example, have their own forks of the library. I've solved this by using the MutationObserver trick described above, and it generally works well, with two caveats: - I don't know (yet) what the performance impact of this will look like - Writing to an attribute will only reflect the written value to the wrapped object's property once the MutationObserver invokes its callback, which creates some (slightly) confusing behavior in some situations (for example, in my tests for this assignment logic, I need to run my assertions in a `setTimeout` callback because otherwise the new value would not have been forwarded yet.) I understand why things are the way there are and wouldn't even want to go anywhere near suggesting a change -- I merely wanted to present an (admittedly unusual) use case in the hopes that maybe new patterns will emerge in the future. (For example, it would rock to be able to imperatively update the `observableAttributes` list at runtime -- I could then do this from within my constructor code once it actually has an instance of the wrapped class whose properties it could then walk and make a list of.) (Or, alternatively, letting me tell the mechanism to yes, please run the attributeChangeCallback for *any* attribute change. :b) Thanks & stay healthy! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/565#issuecomment-761578383
Received on Saturday, 16 January 2021 15:06:38 UTC