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

On Tue, Feb 18, 2014 at 5:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.
>

Would that cause issues with the order of the mutation record reported by
mutation observers?


>
> > 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
>



-- 
erik

Received on Tuesday, 18 February 2014 23:11:40 UTC