docs: Improve no-child-traversal-in-connectedcallback

[silverwind]

1. Calling MutationObserver#observe without options is invalid and raises a TypeError.
2. When custom elements are rendered with Vue, I noticed the children are available during connectedCallback and the suggested MutationObserver method does receive any mutation events. I assume Vue must use .innerHTML or similar method to append the component to the DOM.

[43081j]

do you have an example somewhere of the 2nd point?

sounds unusual so would be good to get our heads around it before we document it.

even if they add the outer nodes themselves, surely the custom element is responsible for its own children. are we talking about a situation where there's no shadow DOM? etc. think i just need to see an example

[silverwind]

Yes, I will try to make a jsfiddle to demonstrate. If it really is .innerHTML causing this, I will remove the reference to Vue specifically.

[silverwind]

Reproduced with these in Firefox, Chrome and Safari:

• WC in HTML content. children empty during connectedCallback. Mutation triggers.
• WC inserted via innerHTML. children available during connectedCallback. No mutations.

My conclusion is that a WC that wants to reliably access its children needs to do something like this to be compatible to both rendering methods:

connectedCallback() {
  if (this.children.length) 
    // access this.children
  } else {
    const observer = new MutationObserver(() => {
      observer.disconnect();
      // access this.children
    }).observe(this, {childList: true});
  } 
}

[43081j]

ok now i understand 👍

i don't think this is actually something to put in the reasons for not using the rule. i think its the example which is poor

in one of my projects, i have roughly the same pattern but with the initial call like you suggested:

constructor() {
  this._observer = new MutationObserver(...);
}

connectedCallback() {
  // initial call because the observer will observe from the next change
  this._onChildrenChanged();
  // observe so followup changes trigger too
  this._observer.observe(this, {childList: true});
}

i think we should just make the example clearer - calling the observer's callback as well as observing

[silverwind]

Can you share all related code so I see how you handle it?

BTW, I think the second example with the addEventListener('update') is also poor, because I don't know what this update event is and what triggers it. I think such examples should be fully self-contained to be useful.

Maybe @keithamus also wants to chime in.

[43081j]

basically the pattern we use in our projects are roughly this (off the top of my head so not exactly the code from our repos):

class FooElement extends HTMLElement {
  constructor() {
    this._observer = new MutationObserver((change) =>
      this._onChildrenChanged(change));
  }

  _onChildrenChanged(change?) {
    // do things now that child nodes changed
    // if `change` is nullish, treat it as if all children changed
  }

  connectedCallback() {
    this._onChildrenChanged(); // Call it immediately for any already-appended children

    this._observer.observe(this); // Observe the light DOM from now on
  }
}

the examples of "correct code" in the docs are meant to be simple though. so if we end up having to document a more complex example like this, im skeptical of if we should even keep it

it may just not be worth mentioning mutation observer, or we do a cut down version of this example

[silverwind]

Thanks, I see you are using the same basic concept I do, the only difference is that you call _onChildrenChanged unconditionally while I actually verify presence of at least one child, because in my case my component has one mandatory child element.

Your method would trigger _onChildrenChanged even when there was no actual change to children, for example when there are none.

BTW, as seen in WICG/webcomponents#809, it is a popuplar request for the standard to include a lifecycle callback once children are available, but so far there has been no movement on it. Honstly I'm really surprised that such basic functionality is missing in the standard.

[keithamus]

I don't think we should add this because it's typically not possible to know what happens to your element, as it is up to the consumer how it is embedded.

For example if your element is appended to the DOM using append(), and you have disabled this rule, your code breaks. If your element is served from the source HTML, and browser decides to render, your element is connected but incomplete, you code breaks.

The point of this rule is to remind you that those cases exist, and to carefully think about how you want to approach them.

[silverwind]

I agree, disabling the rule as a whole is definitely too crude. I think a eslint-disable-line would be suitable for cases where you know exactly how your element is going to be inserted. Maybe it should just recommend that.

[silverwind]

I think we could at least hint somewhere in the rule text that depending on the renderer, children may be available or not and I think any universally usable component that deals with its children has to check for both immediately and delayed availability of children.

I just fear that people who blindly follow this rule will create components that can not work correctly when inserted via .innerHTML, which I think is very common with frameworks like React or Vue.

[keithamus]

BTW, as seen in WICG/webcomponents#809, it is a popuplar request for the standard to include a lifecycle callback once children are available, but so far there has been no movement on it. Honstly I'm really surprised that such basic functionality is missing in the standard.

The main reason is that people cannot decide how to correctly approach it. There is debate on whether or not elements deferring their logic until they see their closing tag is an anti-pattern. And for cases other than that, it seems there are multiple ways a component can consider doing setup: using a MutationObserver or deferring work until some event is fired.