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

On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 1/9/14 10:57 PM, Ryosuke Niwa wrote:
>>>
>>> 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...
>
>
> Right, I did say that above.  Is that really a problem in practice, though?
>
>> 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.
>
>
> Isn't that the bad thing we _don't_ want to do?  That is, invoke arbitrary
> page JS from the middle of the parsing algorithm?
>
>> 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.
>
>
> The parser is expected to insert the nodes into the document pretty much
> immediately after creating them, no?
>
> -Boris
>

Calling of constructors (in JS/ES sense) instead of callbacks is not
semantically correct I would say.

Consider this declaration:

class MyElement inherits HTMLElement {
    public  prop = 1;
    constructor( text ) {
       super("my-element");
       this.textContent = text;
    }
}

UA simply cannot call such constructor as it requires parameter.
UA can call only implicit default constructor,  :  ({ prop:1
}).__proto__ =  MyElement;  in this case.
And call some designated method of the class ('callback' in this
discussion) when element gets
attached to the DOM tree.

Constructors are used for 'external' element creation:

  var myel = new MyElement("woo-hoo!");

About "callbacks":

It should be two callbacks actually:

attached() - called when element *gets attached to the DOM*, it is not
a constructor, sic!
detached() - when it gets detached from the DOM.

so here:

  var myel = new MyElement("woo-hoo!");
  someParent.append(myel);

call of myel.attached() will happen inside the append() above.

  detached() is called when parent.removeChild() for the element is called.

Just in case: this is how it is implemented and works in my Sciter [1]
and I didn't find any problems with element/script life cycles.

And yet. I also have dynamic element class assignment
by CSS with custom 'prototype' property, e.g.:

  input[type="masked"] { prototype: MaskedInput url(code/widgets.tis); }

In that case attached/detached are also called when the element
gets/looses that style. But that's probably another story.

[1] http://terrainformatica.com/sciter


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 10 January 2014 07:54:51 UTC