Re: [w3c/webcomponents] Need a callback for when children changed or parser finished parsing children (#809)

@dogoku the TL;DR of current state of the art is that given the following JS:

```js
// your custom element
customElements.define('my-select', class extends HTMLElement {
  finishedParsingChildrenCallback() {
    console.log('ready to go');
  }
});

// the currently needed utility
customElements.define('the-end', class extends HTMLElement {
  connectedCallback() {
    const {parentElement} = this;
    parentElement.removeChild(this);
    if (parentElement.finishedParsingChildrenCallback)
      parentElement.finishedParsingChildrenCallback();
    else
      parentElement.dispatchEvent(new CustomEvent('finishedparsingchildren'));
  }
});
```

and the following layout:
```html
<my-select>
  <select>
    <option value="1">
    <option value="2">
    <option value="3">
  </select>
  <the-end/>
</my-select>
```

you would know when your custom element, the one containing the select, is ready to setup itself also based on its content, as you can see in this [code pen](https://codepen.io/WebReflection/pen/aboXzaJ?editors=1001).

However, not only this awkward "_hack_" is needed because Custom Elements are missing a callback that tells the component it's OK to set itself up, there's always a chicken-egg issue about when a Custom Element is defined:

  * is it already live?
  * is it predefined and it could land at any time and be reliable in its setup?

The latter case is usually covered by the common situation where you land all custom elements and their content at once, at least via JS, but not necessarily via SSR.

The first point though is problematic, 'cause as soon as you have the definition order of the `the-end` component after a component that needs it, nothing works as expected.

As example, this [other code pen](https://codepen.io/WebReflection/pen/gOYqbqQ?editors=0011) simply defines the `the-end` component after others, and you won't see anything in the console, hence no setup granted.

The proposed feature here, is to inform a generic Custom Elements when such "_end_" of its content is reached, so that everyone can have a single entry point to setup components that depends on their content, same as native `select`, `ul`, `table` or other more complex HTML elements do.

There's a missing primitive that requires a lot of overhead per each component because of such missing information/callback/event, and every framework not based on custom elements has an easier life in setting itself up, 'casue the content is already accessible, which is also not always the case for Custom Elements.

As example, if you have a definition in your document head and the element is initialized while its opening tag is encountered, you need a lot of "_dancing_" to figure out when it's the right time to set anything up.

This is somehow a non-issue when your component uses Shadow DOM, as that's usually done in the constructor, but it becomes a foot gun prone approach when you'd like to have Server Side Render friendly components, and you don't control when these are defined in any hosting site.

I hope this summary helped a little to go back on track with the issue, and any possible solution.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/809#issuecomment-534115603