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

> The fact that you can use MutationObservers after parsing is complete

I think current work around is using MutationObservers on constructor, hence before the parsing is complete.

> I generally fire events from children when they're ready to interact with an ancestor

That works only if children are Custom Elements.

A `<sortable-list>` might be a container for an `UL` and some `LI`, and knowing when the content is ready is crucial when it comes to setup.

Imagine the server producing the following based on same data:
```html
<sortable-list>
  <ul>
    <li>a</li>
    <li>b</li>
  <ul>
</sortable-list>
```

If you define upfront the `sortable-list` component, and you don't want to use ShadowDOM, which _shouldn't_ be mandatory to setup Custom Elements, the only way to do that is to use a hack via [html-parsed-element](https://github.com/WebReflection/html-parsed-element) or similar, or to use MutationObserver within the `constructor` so that the component will inevitably flick due asynchronous nature of the MO.

I think @rniwa here nailed the issue me, and others, are complaining about.

> I think there is legitimate scenarios in which the most natural solution authors think of is finishedParsingChildrenCallback.

Anything else would result in probably nice to have, but not an answer to the real issue.

The fact built-in elements don't have such lifecycle is misleading, 'cause a `<select>` internally setup likely once, instead of N times synchronously per each discovered `<option>` with it.

We, users, simply don't get to know when that setup should happen, which is independent of the usage of MO in case the component should be able to rect on added/removed nodes, 'cause these are not mutually exclusive scenarios.

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