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

> That seems like a serious forward compatibility issue to me.

Thanks for the careful analysis; I think I agree.

> Another somewhat different fix here might be that avoid invoking connectedCallback or disconnectedCallback when the condition isn't met.

The idea here would be, that we'd add something to https://html.spec.whatwg.org/#invoke-custom-element-reactions which is like "If the callback reaction's name is 'connectedCallback', and the element is not connected, skip this callback function"?

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. 

I don't have good intuition one way or the other here, and would love to hear more from others (especially authors).

Also I wonder if you have similar thoughts about attributeChangedCallback? Like, if the attribute's current value is not equal to the newValue argument, should we avoid calling attributeChangedCallback?

-- 
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-443014777