RE: Custom element design with ES6 classes and Element constructors

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.

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?

> 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.

Received on Tuesday, 13 January 2015 00:24:47 UTC