Re: [WICG/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

I am not sure this thread is the right venue for these kind of conversations ... but here my answers:

> it's confusing that eo.observe(el) triggers connectedCallback but eo.disconnect(el) doesn't trigger disconnectedCallback.

it's based on Custom Elements behavior, where `connectedCallback` is called even if the element was already live.

`eo.disconnect(el)` is based on current MutationObserver behavior. If you call disconnect you'll stop having notifications from that observer. While I agree these might be confusing, as similarly named, the element is not technically disconnected from the DOM, so I am not sure that should be called.

If we use `connected/disconnectedCallback` as seatup.teardown down, then *maybe* both callbacks should be renamed, like I've done with [builtin-elements](https://github.com/WebReflection/builtin-elements#api) library. In this case, I see `observedCallback` and `unobservedCallback` decent candidates, but I'd be happy to change/re-think these too.

> eo.disconnect(el) only means EO will no longer call your callbacks on DOM changes.

exactly like MutationObserver works ... you stop observing the element, nothing triggers anymore.

> attr changed callback is called before connected callback when the element is added to dom with an observed attribute. 

exactly how Custom Elements work. The attributeChangedCallback is always triggered before connectedCallback if an element is upgraded and one of its attributes is observed.

Moving away from the current standard lifecycle doesn't look like a good idea, imho.

> If connectedCallback comes first, I could put my initialization there

this is abusing the meaning of connected/disconnected which is, in Custom Elements world, about these elements being upgraded and live on the DOM, or removed. The right place to setup listeners once is the constructors, but here we don't have one, so that `observedCallback` or `upgradedCallback` and `downgradedCallback` or `unobservedCallback` would be a better place for that. This is how previously mentioned **builtin-elements** library works. Agreed it's better ergonomic, not there by accident indeed.

> if you make many changes to the elem at once (the mess button), your callbacks will be called multiple times

This is how Custom Elements work. The only difference here is that Mutation Observer callbacks are asynchronous and nobody can know upfront if other callbacks were queued/scheduled, without further delaying the reaction.

The order is guaranteed to be the correct one though, the sequence is always exactly the one that happened live.

However, `element.isConnected` is the only source of truth, and removedElements list might contain nodes that are live again, but the code will know only after parsing the next record.

This is how MutationObserver works, nothing I can do, and a well know tiny caveat of all Custom Elements polyfills to date that are based on the asynchronous nature of the Mutation Observer.

Synchroonus DOM mutation events are deprecated for good, and I don't want to over-complicate in my library this dance, as there is no effective way to avoid multiple calls, all I can guarantee is that the sequence is correct (i.e. by triggering removedNodes *before* addedNodes*).

I hope this answered all your findings/questions.

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