Discussion on: Web Component developers do not connect with the connectedCallback (yet)

[𒎏Wii 🏳️‍⚧️]

Depends how you do it, I guess?

I assume you're mostly considering using innerHTML here, which I tend to stay away from whenever possible, so to me that falls in the remaining 2%.

Building a custom element in JS (including children) and then inserting it into the page will run the callback on a populated component. If you want to add elements afterwards, then you probably need a MutationObserver anyway, because you'll likely want to continue monitoring for changes for the entirety of the components life-cycle, not just for some initial "setup" phase where you continue adding children manually.

[Danny Engelman]

It has nothing to do with innerHTML It doesn't matter how you add DOM to your existing page, readystatechange will never fire again after the first pageload.

[𒎏Wii 🏳️‍⚧️]

I don't think I understand what requirements you have towards your custom elements then.

I see two settings:

a) A custom element should consider its child elements when it is created and do some stuff with those, but can afterwards become inert because the contents of the element are static at that point.

b) The component should respond to insertions and deletions throughout its entire lifetime and update its internal state accordingly on every change.

In the first case, the site load is the only problematic part, because the element gets inserted into the DOM before its children have been parsed. When creating the element from javascript, the child elements are already there by the time the element is connected, so the connectedCallback will work just fine.

In the latter case, inserting items initially is really just a not-so-special case of inserting items at any point during the object's lifecycle, so no special code is required here.

The dynamic case can usually be achieved relatively easily with a generic MutationObserver that dispatches an event or calls a method on its target.

[Danny Engelman]

There is no requirement, there is a fact.

This blog is (an attempt) to explain why there is no innerHTML when the Web Component is defined before the DOM is parsed

Almost all Web Components posted on X in the last month, fall into this trap.. and don't work in 100% of cases.

<script>
  customElements.define("my-component", class extends HTMLElement {
    connectedCallback() {
        console.log(this.innerHTML); // empty string!
    }
  });
</script>

<my-component>Hello World</my-component>

Yes, you can solve part of the issue with a MutationObserver; that is like taking a sledgehammer to drive in a nail.

[𒎏Wii 🏳️‍⚧️]

I think this conversation is going in circles.

To reiterate:

• A simple readystatechange event listener can fix the problem where custom elements appear in the HTML sent from the server
• If you insert them using JavaScript, you can populate them before insertion
• If you need to insert elements after connecting to the DOM, you need the sledge hammer

Most of your post makes perfect sense, but towards the end you start to consider a weird case that I don't exactly get where you insert a custom element from client-side code, but you talk about it like DOM parsing is still a factor here, which I don't understand how that would be the case.

Going back to the code in my original comment:

connectedCallback() {
   if (document.readyState === "loading") {
      return document.addEventListener("readystatechange", this.connectedCallback, {once: true})
   }
}

and the example you provided

const body = document.body;
body.addEventListener("click", (evt) => {
   body.append( document.createElement("my-cool-component") );
}

Maybe you could explain what would have to happen for this to fail? There's no child-elements being added to the component in your example, so I don't see where the problem is supposed to come from.

[Danny Engelman]

Yes, that is a a wrong answer in my comment, I re-read the blog post; looks fine to me.

I added a better reply to your readystatechange .

Full working (and readystatechange failing) JSFiddle is: jsfiddle.net/WebComponents/d9sbzcex/

Note: As I said in the blog, WebReflection wrote a parsedCallback that fires when all child Nodes are available.
github.com/WebReflection/html-pars...
It uses the document readyState, MutationObserver and lost more MJ... and is 77 lines of code

The one liner setTimeout will get you the next N Child Nodes

N can be scary for developers who only believe in digital 0 and 1 values, and can't deal with quarks or Schrodingers cat when programming.