Lifecycle hooks independent of ownerElement

[sorvell]

Let's define lifecycle callbacks taking into account the element and the attribute as a whole. Review use cases to see if element-specific hooks are needed.

source

use case

When using attribute for instructions to setup behaviors like, for example, data binding, it seems very useful to be able to do this while the element is not in the DOM. If the ownerElement is not set in the constructor (see #1), then a signal for this, independent of DOM connection, would be needed. However, DOM connection of the owning element is also relevant for things like external event listeners. That would suggest the need to have ownerAdded/Removed in addition to ownerConnected/Disconnected, but this definitely adds complexity and makes it setup/teardown location use case specific.

existing behavior of isConnected

Additionally, there's a (slightly stronger than bike-shedding) naming issue with connectedCallback since attributes currently have an isConnected property which is always false. It would be pretty strange to have connectedCallback called when isConnected is false. It might be possible to change attr.isConnected, but it adds stress since a web compatibility study would be required.

callbacks with multiple meanings

The proposal suggests that adoptedCallback and connected/disconnectedCallback be called in cases where the triggering action is fairly different. The connectedCallback case seems most straightforward since similar setup work is likely required for (1) an attribute being connected to an element in the DOM or (2) an element with an attribute connected to the DOM. However, if an attribute is removed when an element is disconnected, there would be no signal other than adoptedCallback. Calling adoptedCallback when the ownerElement changes or the ownerDocument does seems hard to justify since these are very different state changes.

proposed simplification

Building on the suggestion in #1, if ownerElement must be set in the constructor and cannot change other than becoming null, then this set of callbacks might work:

• constructor: called with ownerElement always set. Do document independent element related setup.
• ownerConnectedCallback: called when the ownerElement is connected to the document. Do document dependent setup.
• ownerDisconnectedCallback(): called when the ownerElement is disconnected from the document. Do document dependent teardown.
• ownerRemovedCallback(): called when the ownerElement is set to null (ideally either before this happens or with a oldOwner argument). Do document independent teardown.
• ownerAdoptedCallback(): called when the ownerElement changes documents. Do advanced x-document work.
• ownerAttributeChangedCallback(...)

This would still require teardown work to potentially occur in 2 places which isn't ideal, but they are distinct cases and can always route to the same teardown function.