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

Danny-Engelman left a comment (WICG/webcomponents#551)

Another year gone, lets keep the topic alive.

FYI, that **<last-element-in-lightDOM>** _"solution"_ has been around for many HTML/JS moons with the esoteric notation:

```<style onload="this.parentElement.parsedCallback?.()"></style>```

or even more esoteric:

```<img src="" onerror="this.parentElement.parsedCallback?.()">```

or any tag that triggers an "I was parsed" notification (and knows its scope)

At least those do not fail when someone-else got "into" the page earlier and defined his/her/[pronoun] ``<parsed-element>``

The root cause (by design) is that the DOM parser triggers the ``connectedCallback`` after parsing the **opening** tag.  
That is why you can access _attributes_ in the ``connectedCallback``. But lightDOM may not have been parsed.

If you use ``type=module`` or whack ``defer`` on your script, it will execute (very) late, after all DOM was parsed.

If you want to prevent FOUCs, you need to ``customElements.define`` your Web Components as early as possible.

If you know your application, and (light)DOM was NOT parsed, you can get away with:

````javascript
connectedCallback(...args) {
  this.myconnectedCallback?.(...args)
  setTimeout( () => { this.myrenderedCallback?.( ) } , 1 )
}
````
Never had any issues, but I don't stick 100s of Nodes in lightDOM.
That will fail, its still async, the DOM parser might still be busy parsing the page.

Or use ``requestAnimationFrame`` or ``queueMicrotask``

Give the DOM parser some extra time to parse that lightDOM.

The more complexity you put in lightDOM the longer parsing takes; nested Custom Elements will all trigger their ``connectedCallback`` _**on the opening tag**_

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

Message ID: <WICG/webcomponents/issues/551/4171021429@github.com>