Re: Custom element design with ES6 classes and Element constructors

> On Jan 12, 2015, at 4:24 PM, Domenic Denicola <d@domenic.me> wrote:
> 
> From: Ryosuke Niwa [mailto:rniwa@apple.com] 
> 
>> In that case, we can either delay the instantiation of those unknown elements with "-" in their names until pending module loads are finished
> 
> Could you explain this in a bit more detail? I'm hoping there's some brilliant solution hidden here that I haven't been able to find yet.

There's no brilliant solution here.  I'm suggesting to introduce something akin to sync script element.

> For example, given
> 
> <my-el></my-el>
> <script>
>  window.theFirstChild = document.body.firstChild;
>  console.log(window.theFirstChild);
>  console.log(window.theFirstChild.method);
> </script>
> <script type="module" src="my-module.js"></script>
> 
> 
> with my-module.js containing something like
> 
> 
> document.registerElement("my-el", class MyEl extends HTMLElement {
>  constructor() {
>    super();
>    console.log("constructed!");
>  }
>  method() { }
> });
> console.log(document.body.firstChild === window.theFirstChild);
> console.log(document.body.method);
> 
> 
> what happens, approximately?

In this particular example, my-el will remain HTMLUnknownElement since it had already appeared when the script element to load the module is parsed.  A more interesting example would be the one where the script element to load my-module.js appears before my-el.  In that case, the instantiation of my-el is delayed until my-module.js is loaded.

>> or go with option 2
> 
> There are a few classes of objections to option 2, approximately:
> 
> A. It would spam the DOM with mutations (in particular spamming any mutation observers)
> B. It would invalidate any references to the object (e.g. the `window.theFirstChild !== document.body.firstChild` problem), which is problematic if you were e.g. using those as keys in a map.
> C. What happens to any changes you made to the element? (E.g. attributes, event listeners, expando properties, ...)
> 
> I am not sure why A is a big deal, and C seems soluble (copy over most everything, maybe not expandos---probably just follow the behavior of cloneNode). B is the real problem though.
> 
> One crazy idea for solving B is to make every DOM element (or at least, every one generated via parsing a hyphenated or is="" element) into a proxy whose target can switch from e.g. `new HTMLUnknownElement()` to `new MyEl()` after upgrading. Like WindowProxy, basically. I haven't explored this in much detail because proxies are scary.


B is problematic only if authors are not responding to DOM mutations.  If we feel that B is too problematic then we should go with option 1 with the aforementioned synchronous delay.

- R. Niwa

Received on Tuesday, 13 January 2015 00:41:10 UTC