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

> We are supposed to support an event of change of slot.getAssignedNodes({flatten: true}), rather than slot.getAssingedNodes(), aren't we?
>
> In this case, one DOM mutation potentially would have a global effect, which would cause the update of distributed nodes of any slots in descendant trees. Yeah, this is a cascading effect and this could not be done in O(1). In practice, this might not be so expensive, but this could be expensive, in theory.

Not necessarily. It all depends on how you implement this feature but there is a strategy by which detecting that is O(1) as well.  For example, when a slot element A is inserted as a child of a shadow host C, it could look up whether A is assigned to another slot B in its shadow DOM of C.  If it is, it can notify the shadow root that contains B as a direct descendent that B now contains C.  We can then store reference to B's shadow root in A.  When a node is assigned into A, it can then notify B via its shadow root.  You can do this recursively so that A remembers all slots into which it could be flattened into.  One downside of this approach is that it could result in O(k) storage space where k is the number of slots into which a slot gets flattened through as well as potential O(k) runtime when a slot is inserted into / removed from a shadow DOM on the premise that slots are rarely inserted/removed.

Alternatively, you can take the approach I described earlier, and walk up the "flattening chain" in O(k).  I think this latter approach is better because a node getting kept being re-distribute in rare in practice and it tends to be bounded by a small number and doesn't require an extra storage in memory.

Anyway, this O(k) runtime/memory cost is precisely the reason we didn't want to support detecting changes to the list of distributed nodes but if all JS libraries are going to implement themselves, it would be MUCH worse.

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