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

On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
>
>
>
> On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>>
>> What I mean is that for nodes that doesn't have a constructor, and
>> whose parent doesn't have a constructor, no need to add them to the
>> above arrays. Just insert them into their parent. That means that when
>> that the constructor of an element runs, the element doesn't have any
>> parents or children.
>>
>> So no need to hide parents or children anywhere.
>
>
> Okay, let me see if I got this right. The list is effectively a serialized
> representation of a document subtree. The parent + order in the list
> provides all the necessary information. We use this list to separate tree
> construction into two stages: one before custom element constructors are
> called, and one after.

Yes

> In cases when the custom element is just a like button widget (a leaf in the
> tree), the list is short and just contains the widgets.

Yes

> In cases like "<body><my-app><div> ... the entire doc tree ...
> </my-app></body>", the list contains the entire subtree of <my-app>, which
> is effectively the document.

Well. With the optimization I mentioned you only need to make the
<my-app> element and it's immediate children into the list. Any
grand-children of <my-app> can immediately be inserted into their
parent.

So I guess you could say that the list contains basically the whole
document. But most nodes would only indirectly be in the list. I.e.
the list would be short, but each entry could contain large subtrees.

> In cases like "<div><my-bar>..</my-bar><span>...</span> ... more siblings
> ... </div>", the list will contain at least all siblings of <my-bar>,
> because they can't be inserted into tree until after <my-bar>'s constructor
> runs.

Yes

> When run, the constructors are free to explore the partially-completed tree,
> which enables interesting hacks like this:
>
> in document:
> <div id="a"><my-bar></my-bar>.... lots more markup...
>
> in my-bar constructor:
> var myFutureParent = document.querySelector("#a");
> // redirect tree construction to resume at a new point.
> document.body.appendChild(myFutureParent);
>
> Or, in my-bar constructor:
> var myFutureParent = document.querySelector("#a");
> var iframe = document.body.appendChild(document.createElement("iframe"));
> // teleport the tree into another frame
> iframe.contentDocument.body.appendChild(myFutureParent);

Yup

> I can't immediately tell whether these hacks are cool or scary.

You can already do exactly this with <script> elements. I also am not
sure if that's cool or scary. But I also haven't heard of anyone
running into trouble because of it. I suspect it's not a common thing
to do.

> The thing that really bothers me is that this approach is contradicting
> itself. We go to into pretty elaborate lengths to enable running
> constructors during parsing, but the key performance lesson developers will
> immediately learn is to avoid constructors on custom elements, because they
> will trigger the two-phase code path during parsing. Here's a thing that you
> can use, but you probably don't want to ever use it.

The above paragraph appears to assume that creating this list is slow.
Do you have data to back that up?

The whole premise of my original email was that we should not do this
if it's slow. And that we should measure if it's slow or not.

I absolutely agree that we should not add features that are slow
anytime they are used.

/ Jonas

Received on Tuesday, 18 February 2014 23:00:19 UTC