Maybe this is a stupid question, but why does the `slotchange` event exist? A mutation observer can do the one thing slotchange can do, but also much more. #javascript #WebComponents #shadowDOM
@noleli It鈥檚 kind of the same argument for using `.reduce()` for every array use case, right? 馃榾 The multi-tool might be powerful, but sometimes you just want the tool that does one thing and does it well.
@knowler @noleli Pretty sure it鈥檚 for ergonomics鈥攏o need to create and manage an observer for this common case鈥攁nd (more importantly) performance reasons. Although MOs may be relatively cheap, they鈥檙e not free; you probably don鈥檛 want a large DOM tree full of them, and since the browser code to implement slotting already knows whenever a change occurs, it鈥檚 cheaper just to fire an event.

@graynorton @knowler all good points! The event is certainly easier to manage. This came up because I was wishing the event object had some detail similar to a childList mutation record that said what was added or removed.

@tbroyer also made the excellent point that a MO isn鈥檛 going to handle manually assigned children, which is something I鈥檇 forgotten. (@deebloo also just added that)

@noleli @graynorton @knowler @tbroyer honestly sometimes I avoid the whole thing my manually calling methods on the parent. Child notifies parent it is being added or removed. https://github.com/deebloo/go-board/blob/main/src/stone.element.ts#L54
go-board/src/stone.element.ts at main 路 deebloo/go-board

Go Board WebComponent. Contribute to deebloo/go-board development by creating an account on GitHub.

GitHub

@noleli It wouldn't account for manually assigned elements, and you'd otherwise obviously have to reimplement the slot matching that the browser already does to assign elements to slots by name.

If `slotchange` didn't exist, you'd likely ask why you'd have to reimplement what the browser already knows and "it could just fire an event when things change" 馃槈

@noleli timing is an issue. Mutation observers only fire when something changes. So they won't fire on the initial value (slot change will). Also if you use dynamic slot assignment (change slot but not children) MO wont fire
@noleli I do wish slotchange would tell your WHAT changed. Like how MO has which nodes were added and removed.

@noleli A Mutation Observer CANNOT do the one thing a slotchange can do and that is observe changes through multiple slots...

However, there are lots that a Mutation Observer can do that a slotchange event _could/should_: https://github.com/WICG/webcomponents/issues/933

Options for controlling specifics of "slotchange" events? 路 Issue #933 路 WICG/webcomponents

By default a <slot> observes its children with just about the least complex options of a Mutation Observer. Essentially, new MutationObserver((mutationsList) => { for(const mutation of mutationsLis...

GitHub
@westbrook that鈥檚 a great, flexible suggestion. @deebloo and I were talking about a more limited form of this https://indieweb.social/@deebloo/110741171674282080