rfc: introduce "connected" and "disconnected" lifecycle hooks to FASTElement

[nicholasrice]

💬 RFC

A feature I've been considering recently is the addition of a "connected" and "disconnected" lifecycle hook to FASTElement instances. These callbacks would be invoked by the ElementController just prior to exiting the connect() and disconnect() methods, respectively.

🔦 Context

Why would we want this? The browser already calls connectedCallback() and disconnectedCallback(), right? It does, but there-in lies the problem. In SSR scenarios, the defer-hydration attribute will prevent the ElementController from performing hydration work during the connectedCallback, including initializing template bindings, connecting behaviors, and re-binding observable values, only doing so after the defer-hydration attribute is removed. This means the element and ElementController's state within the connectedCallback could be very different between CSR and SSR+Hydration.

By introducing connected (and disconnected) and invoking the hooks from the ElementController, authors can craft components that operate under more consistent conditions between CSR and SSR + Hydration. Additionally, using these hooks and failing to call the super method would not break the ElementController.

💻 Examples

class MyElement extends FASTElement {
    connected() {
       // Always invoked after the ElementController has done connection work,
       // either during connectedCallback() in CSR scenarios or asynchronously
       // during defer-hydration scenarios.
    }
}