Re: Why can't we just use constructor instead of createdCallback?

Jonas, William, Ted, and I had some discussion about this last month.  (Sorry for the delayed response).

On Dec 5, 2013, at 10:58 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
> On 12/6/13 1:49 AM, Ryosuke Niwa wrote:
>> Then how do we define a custom element using ES6 classes?  Are we going to not call the constructor?
> 
> An excellent question, indeed.  I don't have a good answer for you.
> 
> If we do make elements subclassable (which it seems like we should), we would presumably need to make the actual default constructor of the built-in element classes a no-op, since we can't actually rely on the subclass calling it.  All the relevant setup would need to be done by @@create.
> 
> Given that, we could maybe cheat and in fact do some sort of delayed calling of the constructor of ES6 subclasses of elements.  You'd still be able to observe these objects in an "unconstructed" state from the subclass pov, but at least it wouldn't be a security issue in terms of operating on a DOM that's in an inconsistent state from the point of view of privileged code.

Calling constructors after the tree had been constructed will be an issue because then you could access “unconstructed” nodes via nextSibling, parentNode, etc...

> It's not clear to me how OK such an "unconstructed" state is.  I suppose it's no worse than someone extending the ES6 subclass in question and then never calling its constructor...  But that's a programming error on the someone's part, typically, while here we would be effectively forcing this sort of thing on all Element subclasses.
> 
> All that still seems more palatable than trying to completely revise HTML parsing to be robust to constructors running when the element is created….

One idea that came out of our discussion is was to add an additional step in the parser to call constructors on all “pending” elements before they’re being constructed into the DOM tree.


On Dec 6, 2013, at 7:05 AM, Erik Arvidsson <arv@chromium.org> wrote:
> The custom element draft does add a new synchronization point. After setting innerHTML (for example), before returning to the script the callbacks for the custom elements created by innerHTML are called in tree order.
> 
> This does lead to the possibility to observer objects that have not yet had their created callback been called yet. I think this trade off is inevitable, no matter whether we use @@create, constructor or created. I just don't see us being able to call user code every time a node is created.


I do understand your concern.

On Dec 6, 2013, at 7:37 AM, Erik Arvidsson <arv@chromium.org> wrote:
> The things that fail here are:
> 
> 1. The parser does not know that it needs to use MyElement.@@create to create the JS objects when it sees a <my-element>.

On the other hand, solving this seems to require running some author scripts at the element creation time, at some later time but before the node is inserted into the document.

> 2. No callbacks for enteredView, leftView and attributeChanged.
> 3. It depend on the magic of document.createElement which is circular. A better way would be to do `super('my-element')` or something like that.


- R. Niwa

Received on Friday, 10 January 2014 03:57:57 UTC