Re: Custom element design with ES6 classes and Element constructors

In ES6 the constructor does both allocation and initialization. At
upgrade time it is too late to do allocation so we cannot call the
constructor at that time. We would need a callback for this, call it
upgradeCallback for example.

When the parser sees a custom element (any element with a dash in it)
it queues a reference to this element without creating a JS wrapper.
Before executing a script we need to empty this queue and we can do
that by [[Constructing]] the wrappers for these elements, looking up
the constructors in the registry. This is similar to how
createdCallback is handled today.

This means that the constructor can be used if the local name has been
registered but that the constructor will not be called for upgrades.
User code can structure their code in a way that they can share
initialization code.

class MyElement extends HTMLElement {
  constructor() {
    super();
    this.init();
  }
  upgradeCallback() {
    this.init();
  }
  init() {
    ...
  }
}
document.register('my-element', MyElement);

There is also some issues related to the parameters passed to the
constructor and it looks like we need to use species for elements
created by the parser but I'll let Domenic cover that area.

On Mon, Jan 12, 2015 at 12:42 PM, Domenic Denicola <d@domenic.me> wrote:
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>
>> Proto munging isn't even that big of a deal. It's the back-end stuff that's kinda-proto but doesn't munge that's the problem.  This is potentially fixable if we can migrate more elements out into JS space.
>
> It really isn't though, at least, not without a two-stage process like empty constructor() with [[Construct]] semantics that can never be applied to upgraded elements + createdCallback() with [[Call]] semantics that can be applied to upgraded elements after having their __proto__ munged.



-- 
erik

Received on Monday, 12 January 2015 20:06:33 UTC