[idea] childConnectedCallback and childDisconnectedCallback

[trusktr]

I think having such methods would make it much easier than using MutationObserver for doing things when children are connected to a custom element.

Some reasons:

• Suppose we wish to use connectedCallback to initiate a mutation observer, and disconnectedCallback to disconnect the observer, rather than initiating it in createdCallback or constructor. This has the side-effect that by the time connectedCallback is fired that the custom element may already have had children added to it, so the mutation observer won't catch those.

• Using MutationObserver requires writing at least two nested for loops, which is much more verbose than simply placing logic inside a childConnectedCallback(child) method. f.e. compare

  connectedCallback() { // or perhaps in createdCallback or constructor?
      const observer = new MutationObserver(changes => {
          for (let change of changes) {
  
              for (let node of change.addedNodes) {
                  if (node instanceof MotorHTMLNode)
                      this.imperativeCounterpart.addChild(node.imperativeCounterpart)
              }
  
              for (let node of change.removedNodes) {
                  if (node instanceof MotorHTMLNode)
                      this.imperativeCounterpart.removeChild(node.imperativeCounterpart)
              }
  
          }
      })
      observer.observe(this, {
          childList: true
      })
  }

  vs

  childConnectedCallback(node) {
      this.imperativeCounterpart.addChild(node.imperativeCounterpart)
  }
  childDisconnectedCallback(node) {
      this.imperativeCounterpart.removeChild(node.imperativeCounterpart)
  }

• The API is just easier, which is a good thing for people learning the Custom Element API.

On a similar note, it may be nice to have element-specific methods. For example (and as a possible alternative to my distributedCallback idea), HTMLSlotElement could have a childDistributedCallback(child) method, and it wouldbe possible to make a Custom Element that extends from HTMLSlotElement and to use it in place of the default <slot> element.

class MySlot extends HTMLSlotElement {
  childDistributedCallback(child) {
    console.log('Child distributed into this slot:', child)
  }
}

customElements.define('my-slot', MySlot)

<some-shadow-tree>
  <my-slot>
  </my-slot>
</some-shadow-tree>

I know we'll be able to use slotchange events, but the methods might be easier to work with.

[rniwa]

In v0 API, there was childrenChangedCallback at one point. I think it got removed due to performance reasons.

[WebReflection]

it's also an overlap with MutationObserver that can be easily simplified through user-land libarries or generic Custom Element class that implements observable changes in its constructor (or add/removes them once connected/disconnected)

[rniwa]

MutationObserver doesn't get invoked until the end of microtask whereas custom element callbacks get invoked almost immediately so it isn't quite polyfillable.

[WebReflection]

well, it could but that's undesired, hence my suggestion to use MutationObserver instead (even if not quite the same, I guess it's fine for 99% of use cases)

[trusktr]

MutationObserver doesn't get invoked until the end of microtask whereas custom element callbacks get invoked almost immediately so it isn't quite polyfillable.

well, it could but that's undesired, hence my suggestion to use MutationObserver instead (even if not quite the same, I guess it's fine for 99% of use cases)

Actually, I'm running into hitches due to this, which makes it difficult to coordinate some of my connected/disconnected logic with my polyfill.

For reference, my polyfill looks like the following in my WebComponent base class (so notreally a "polyfill"), with code omitted for brevity:

// some code omitted for brevity...

export default
function WebComponentMixin(elementClass) {
    if (!elementClass) elementClass = HTMLElement

    // some code omitted for brevity...

    class WebComponent extends elementClass {

        // constructor() is used in v1 Custom Elements instead of
        // createdCallback() as in v0.
        constructor() {
            super()

            // some code omitted for brevity...

            this.createdCallback()
        }

        createdCallback() {
            // some code omitted for brevity...

            const observer = new MutationObserver(changes => {
                for (let change of changes) {
                    if (change.type != 'childList') continue

                    for (let node of change.addedNodes)
                        this.childConnectedCallback(node)

                    for (let node of change.removedNodes)
                        this.childDisconnectedCallback(node)
                }
            })
            observer.observe(this, { childList: true })
        }

        // Subclasses can implement these.
        childConnectedCallback(child) {}
        childDisconnectedCallback(child) {}

        // some code omitted for brevity...
    }

    // some code omitted for brevity...

    return WebComponent
}

Then, subclasses simply implement the childConnectedCallback and childDisconnectedCallback methods. But, as mentioned, timing issues happen because the observation does not happen in coordination with the connected/disconnected methods, forcing me in some situations to use promises and await to coordinate things in a somewhat ugly and possibly error-prone manner (in my subclasses).

[trusktr]

Updated my previous comment, meant to say

timing issues happen because the observation does not happen in coordination with the connected/disconnected methods

[trusktr]

IMO, it'd be nice that (if this feature existed) that childConnectedCallback and childDisconnectedCallback would be guaranteed to fire before the connectedCallback/disconnectedCallback of the children.

This would allow parents to set up certain things (for example pass a message or state to a child), then allow for the child to react to the message or state in connectedCallback without requiring async coordination or polling. Specifically, a child could detect the absence of a message or state in its connectedCallback in order to easily detect an invalid-parent state.

Similar with distributedCallback and detecting the invalid-slot-parent state.

Currently, my library just silently fails, which is not ideal, and I definitely don't want to introduce polling, and introducing async coordination with promises complicates things a ton, even if using await for cleaner syntax.

[trusktr]

Idea from #559 (comment): callbacks for different types of changes: childUpgradedCallback, childConnectedCallback, childDisconnectedCallback, childAttributeChangedCallback, etc.

childUpgradedCallback could be especially helpful when elements that are already children of a custom element parent are upgraded in the future, as described in #559.