Re: The key custom elements question: custom constructors?

On Thu, Jul 16, 2015 at 12:16 PM, Domenic Denicola <d@domenic.me> wrote:
> From: Jonas Sicking [mailto:jonas@sicking.cc]
>
>> Like Anne says, if it was better defined when the callbacks should happen,
>> and that it was defined that they all happen after all internal datastructures
>> had been updated, but before the API call returns, then that would have
>> been much easier to implement.
>
> Right, but that's not actually possible with custom constructors. In particular, you need to insert the elements into the tree *after* calling out to author code that constructs them. What you mention is more like the currently-specced custom elements lifecycle callback approach.
>
> Or am I misunderstanding?

No, that is a good point. The constructor callback does indeed need to
happen between an element is created and the element is inserted.

I think though that in this case it might be possible that we depend
on very little mutable state between the callbacks. I.e. that none of
the state that we depend on while the algorithm is running can be
mutated by the page.

In essence the only state we need to keep is the pointers to the
elements, and the parents that the elements should be inserted into.
And since pages can't delete any objects, those pointers will remain
valid throughout.

The only thing that I could think of might be tricky is around tables,
where sometimes we don't insert elements last in the childlist of
their parent. In that case we'll also carry state about where to
insert a given child. That state might get outdated since the page can
mess around with the DOM.

>> This is a problem inherent with synchronous callbacks and I can't think of a
>> way to improve specifications or implementations to help here. It's entirely
>> the responsibility of web authors to deal with this complexity.
>
> Well, specifications could just not allow synchronous callbacks of this sort, which is kind of what we're discussing in this thread.

Agreed. What I meant was that if we're specifying synchronous
callbacks, there's nothing we can do in the specification to help with
this type of problem.

> That would help avoid the horrors of
>
> class XFoo extends HTMLElement {
>   constructor(stuff) {
>     super();
>
>     // Set up some default content that happens to use another custom element
>     this.innerHTML = `<x-bar><p>${stuff}</p></x-bar>`;
>
>     // All foos should also appear in a list off on the side!
>     // Let's take care of that automatically for any consumers!
>     document.querySelector("#list-of-foos").appendChild(this.cloneNode(true));
>   }
> }
>
> which seems like a well-meaning thing that authors could do, without knowing what they've unleashed.

Exactly.

/ Jonas

Received on Thursday, 16 July 2015 22:13:27 UTC