Re: [w3c/webcomponents] [idea] distributedCallback for Custom Elements (#527)

Another possibility could be to add a `distributed` or `assigned` event that we can listen to on the element, so in createdCallback:

```js
customeElements.define('motor-scene',
  class extends HTMLElement {
    constructor() {
      this.addEventListener('assigned', e => this.doSomething())
    }

    doSomething() {}
  }
)
```

but, in that case we might as well move the `connected` and `disconnected` methods to the event space too:

```js
customElements.define('motor-scene',
  class extends HTMLElement {
    createdCallback() {
      this.addEventListener('connected', e => this.doSomethingElse())
      this.addEventListener('disconnected', e => this.cleanUp())
      this.addEventListener('assigned', e => this.doSomething())
    }

    doSomething() {...}
    doSomethingElse() {...}
    cleanUp() {...}
  }
)
```

I think just allowing a method to be defined is the simplest way for class-definition time ergonomics:

```js
class MotorScene extends HTMLElement {
  constructor() {...}
  connectedCallback() {...}
  disconnectedCallback() {...}
  assignedCallback() {...}
}
customElements.define('motor-scene', MotorScene)
```

But including the `connected`, `disconnected` (and possibly something like `assigned`) would make the API for retrieving an existing elements and adding behavior to them more clean, otherwise with the class-based methods alone we are limited to monkey patching in the scenarios when we want to modify already-instantiated elements. With events:

```js
document.querySelector('#some-el').addEventListener('assigned', e => {...})
```

---
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/527#issuecomment-230078599