MutationObserver is potentially expensive if we have many elements on the page, especially if there are faster alternatives. Web Components have a built in mechanism for attribute change detection but it is driven from the observedAttributes
static get method.
To use this mechanism we would need a list of all properties of ThreeJS classes at the point we declare the class for each of the matching custom elements. This class is declared in the ThreeElement.for
static function. Unfortunately due to the way ThreeJS implementation is constructed we cannot enumerate the properties of the class until after instantiation of an instance of it since many of the class types only define their properties in their constructors.
I spent a little time today investigating potential approaches, given that observedAttributes
is evaluated at custom element registration time and we cannot re-trigger this evaluation I have had to rule out a number of different options, this leaves the following potential paths as far as I can see:
Continue using MutationObserver
This probably needs profiling to determine if its acceptable on a scene with many objects, I suspect in a large scene this will be a problem.
Instantiate an instance of each class
In this approach we would instantiate each class and then enumerate the object instances own properties. There are a few downsides with this approach in that some of the ThreeJS apis require parameters to be passed in order to cleanly construct, this will then require a bunch of special case code to handle these dummy instances as well as unwinding any sideeffects creating these dummies would cause.
Use typescript to preprocess the ThreeJS types
This would essentially be a build step that could use the TS compiler API to load the types for the ThreeJS api and build a map of class name to attributes. The TS types fully define the interface to the API and this would then allow us to return the appropriate static list of attributes in the observedAttributes
implementation. Downside of course is this requires a build step, and will need to be kept in lcckstep with any Three api changes. Performance however would be good, with a slight payload cost to enumerate all these types and attributes.