- From: Joe Pea <notifications@github.com>
- Date: Mon, 09 Oct 2017 20:21:30 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/447/335349007@github.com>
At the moment, in infamous, I'm observing addition/removal of slots with MO, _and_ using `slotchange` for while the slots are in DOM (my impl is [here](https://github.com/trusktr/infamous/blob/master/src/html/DeclarativeBase.js#L10-L108) and [here](https://github.com/trusktr/infamous/blob/master/src/html/DeclarativeBase.js#L213-L370) and some cases still need to be handled). If `slotchanged` fired when slots were removed and the removed nodes were observable, I might just move to using only `slotchange` and no MO. This is my perspective as someone _using_ Web Components. If I could _easily_ detect distributed and undistributed nodes with only a `slotchange` event, that might be more helpful, but I'm not completely sure yet. It seems to me that it might be more helpful in _some_ cases to have a `distributedchildren` event _on shadow roots_, and in the handler we could detect which slots elements went to and which slots elements were undistributed from (including being able to observe which parent a slot was removed from). A Custom Element (a reusable component) owns its whole shadow root, so it would be okay to have shadow root events like this, because the whole logic is still encapsulated inside the Custom Element. The event of "elements being distributed into a shadow root" seems great for more generic whole-shadow-root logic, and `slotchange` could still be useful for fine tuning specific logic to specific areas of the tree. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/447#issuecomment-335349007
Received on Tuesday, 10 October 2017 03:21:52 UTC