Re: [w3c/webcomponents] connectedCallback timing when the document parser creates custom elements (#551)

@rniwa I can't stop thinking about this

> Alternatively, we could add something like `finishedParsingChildrenCallback`

Now, I don't care about `finishedParsingChildrenCallback` but I'd love to have a `parsedCallback` instead.

Yes, that might never happen if a Custom Element is the entire body of a huge page full of intermediate flushes, but that's a very confined problem, not the most common use case.

Basically, flushing this:
```html
<body>
  <div>
    <my-early-definition <?php
        flush();
        usleep(300000);
      ?>
      key="value">
      <span>ear</span>
      <?php
        flush();
        usleep(300000);
      ?>
      <span>ly</span>
    </my-early-definition>
    <my-lazy-definition key="value">
      <p>lazy</p>
    </my-lazy-definition>
  </div>
</body>
```
It doesn't matter if there is a Custom Element or a `MutationObserver`, the **connected** will never happen until the opening tag is finished (consistently in both Chrome and Safari).

That means that when `attributeChangedCallback` or a mutation record with its `addedNodes` is triggered, the **beginning of the element** is known.

That flush in the middle though, will always trick the browser to early trigger either a `connectedCallback` or an observed mutation within added nodes.

However, what's basically impossible to know in user land but absolutely known behind the scene, is when the closing tag is either enforced or found, so that nodes found after would either be sibling or part of the parent.

That is what I'd love to have in custom elements so that it is possible to understand when the element is fully known or not.

### Scenarios

  * procedural instance creation via `new MyEl` would trigger `parsedCallback` instantly after the `constructor`
  * if the custom element is defined before, the live node is encountered, `parsedCallback` will trigger only once the whole node has been flagged as _parsed_ or _known_ or with a closed tag. Everything else remains the same but at least we have an entry point to setup / flag the component state (or show spinners via CSS and add a class to drop it later on ... and similar stuff)
  * if the custom element is defined after, the `parsedCallback` would trigger possibly before any of the `attributeChanged/connectedCallback` friends but yet, if that's complicated, it's important that triggers ASAP, no matter what.

The `parsedCallback` would provide a primitive mechanism that would make any real-world Custom Element user happy because it exposes an extremely important information that is vital to understand, handle, or setup, reliably in both client and server rendered code Custom Elements.

Thanks for considering that.



-- 
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/551#issuecomment-430386887

Received on Tuesday, 16 October 2018 20:23:58 UTC