Re: [w3c/webcomponents] Presence of disconnectedCallback can expedite an invocation of connectedCallback (#760)

> I see the attraction. However, I'm unsure of the implications for custom element authors, and for the logic they put in their connectedCallback/disconnectedCallback. The element was briefly connected---even if it isn't right now. But the connected logic just gets ignored? Maybe these cases of "quickly connected and disconnected" shouldn't really count as being connected, in which case this change is fine. But I worry about introducing some other unexpected case, where authors are wondering why their callback isn't firing, and their important setup logic not happening.

Right. That's definitely a risk here. But that kind of mutation analysis is probably best done with `MutationObserver` instead so perhaps we're better off [providing that capability to MutationObserver](https://github.com/whatwg/dom/issues/533).

> Also I wonder if you have similar thoughts about attributeChangedCallback?

I think `attributeChangedCallback` is less problematic because there aren't many DOM APIs which mutate multiple element's attributes at once, which is the root cause of the out-of-order reaction delivery being discussed in this issue.

-- 
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/760#issuecomment-443037222