RE: Custom element design with ES6 classes and Element constructors

From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 

> Hmm.  So given the current direction whereby ES6 constructors may not even be [[Call]]-able at all, I'm not sure we have any great options here.  :(  Basically, ES6 is moving toward coupling allocation and initialization but the upgrade scenario can't really be expressed by coupled alloc+init if it preserves object identity, right?

Yes, that is my feeling exactly. The old @@create design was perfect for our purposes, since its two-stage allocation-then-initialization could be staged appropriately by doing allocation initially, then initialization upon upgrading. But the new coupled design defeats that idea.

>> I was hopeful that ES6 would give us a way out of this, but after thinking things through, I don't see any improvement at all. In particular it seems you're always going to have to have `var C2 = document.registerElement("my-el", C1)` giving `C2 !== C1`.
>
> This part is not immediately obvious to me.  Why does that have to be true?

Well, I was skipping several steps and making a few assumptions. Roughly, my thought process was that you want *some* constructor that corresponds to parser/document.createElement behavior. And, since as discussed it definitely can't be your own constructor, the browser will need to generate one for you. Thus, it'll generate C2, which is different from the C1 you passed in.

Even if you removed the assumption that having a (user-exposed) constructor that corresponds to parser behavior is useful, it doesn't fix the issue that the C1 constructor is useless.

Received on Tuesday, 13 January 2015 17:11:27 UTC