Re: [webcomponents] Need "slotting changed" event (#288)

@ajklein ah ok, that makes sense then. The event API *does* have better ergonomics.

@hayatoito re:

> Is that enough as an API?

I'd expect to have some way of seeing what was added and / or removed. One thing that comes to mind is a todo list that persists changes. I would expect to be able to listen for `slotted` events and then persist the changes to some sort of store. I could somehow get the previous state and diff it with the `slot.getAssignedNodes()`, but that would be a lot of effort for something that could easily be provided to me by the event.

For example, if the event is triggered for every distributed node:

```js
slot.addEventListener('slotted', function (e) {
  console.log(e.target); // -> <slot />
  console.log(e.addedNode); // -> `null` or `Node`
  console.log(e.removedNode); // -> `null` or `Node`
});
```

Or if they're batched into a single event:

```js
slot.addEventListener('slotted', function (e) {
  console.log(e.target); // <slot />
  console.log(e.addedNodes); // `null` or `DOMNodeList`
  console.log(e.removedNodes); // `null` or `DOMNodeList`
});
```

I have my reservations about the former since I have first-hand experience with polyfilling mutation observers with mutation events, as well as with using them in massive DOMs (Jira, BitBucket, etc) and the effects on performance they have. Though, if they're non-bubbling, then maybe it's not an issue? Either way, I'm not sure if there's any way to hide the implementation detail of node vs node-list if this information is exposed, so I'd say deciding whether it will be batched or not should be part of this issue.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/288#issuecomment-178548452