RE: The key custom elements question: custom constructors?

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? 

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

Received on Thursday, 16 July 2015 19:17:28 UTC