Re: [w3c/webcomponents] Element.prototype.connectedCallback, et al. (#629)

- and is less error-prone.
  - For example, trying to create `childConnectedCallback`/`childDisconnectedCallback` is problematic with MutationObserver because it is async, this means that if an element is added and removed to/from a few different parents, the `MutationObserver` will enqueue a bunch of `addedNodes` and `removedNodes` in the next mutation callback, and the end developer is likely to loop through all `addedNodes` at once followed by looping through all `removedNodes` at once, which leads to the event handlers being called out of order, and the `parentNode` (for example) of the addedNodes and removedNodes will also not match with the what was actually the case when those events happened. None of these problems would arise if we has a synchronous mechanism like `Element.prototype.connectedCallback` (or other similar synchronous APIs I may have mentioned previously). It would be less error-prone and simpler to implement `childConnectedCallback`/`childDisconnectedCallback` on top of something like `Element.prototype.connectedCallback` (it might be "monkey patching", but I think it's fine for a library author, if done with care).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/629#issuecomment-285899940