When is slotchange handler fired?

[trusktr]

When is slotchange handler fired in the following case?

• A is appended into B, and B already has a shadow dom root so therefore A gets distributed into a slot in B's inner tree, and finally the slotchange event handlers are called. Will the slotchange handlers be called in the same tick as when A's connectedCallback is called? If so, then with this knowledge I may be able to deferr a to a future tick in order to catch the case that a parent motor-node has not made a connection with a distributed motor-node. Does attachedCallback get called before or after slotchange handlers? If after, then I may not even need to defer to a future tick.

[hayatoito]

It's difficult to explain briefly here.
These are now defined in the DOM Standard. The followings might be what you want to read:

• Shadow: define slotchange event whatwg/dom#229
• https://dom.spec.whatwg.org/#mutation-algorithms

[rniwa]

slotchange event fires at the end of the current microtask. Those custom element callbacks fire at the end of current "nanotask" which are basically when UA returns the control back to author scripts from their DOM, CSS OM, etc... APIs. So slotchange tends to fire a lot later than custom elements callbacks in common cases.

[trusktr]

@rniwa How can a distributed node then run some code after slotchange handlers have fired without knowing about slotchange? If slotchange fired in the same tick as the custom element callbacks, then the simple solution is deferring to the next tick.

I would really like to detect when the tree looks like this:

div
 |
slot
 |
motor-node

and I need that distributed motor-node to throw an error when it is distributed into a div.

[rniwa]

I don't follow what you're saying. slotchange event is fired on slot element, not the nodes distributed to the slot.

[trusktr]

@rniwa Yep, that's exactly what I'm saying: that there's no way for a distributed node to know about being distributed because only the parent of the slot or slot itself can work with slotchange, so I suggested distributedCallback as a possible solution.