Stencil needs to be consistent in invoking lifecycle callbacks

[TheCelavi]

This discussion is started under premise that strength of library is directly related to the number and popularity of other libraries in user-land domain, which improves developer experience and solves common issues for which core library does not want to or can not provide solution.

In order to provide a good quality libraries and great DX, Stencil must provide consistent API/behaviour, which currently does not when it comes to lifecycle methods. Namely, critical methods of the component class connectedCallback() and disconnectedCallback() will not be invoked if there is no single component within library which defines those two methods. Reason for that is micro optimisation which provides library benchmark result to compete with others.

I am emphasising these two callbacks (connectedCallback() and disconnectedCallback()) for two reasons:

• Those are from web components public API: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements and they are practically hidden by Stencil (if conditions stated above are met)
• They are critical in allocating resources and auto-cleaning resources which improves DX and quality of libraries for Stencil which can be provided in user-land.

Of course, Stencil SHOULD be consistent - if lifecycle methods are defined via API, they should be either always invoked, or never.

Reason why we are proposing changes in this behaviour is because we just released two experimental libraries for which DX depends on consistency in invocation of lifecycle callbacks, especially connectedCallback() and disconnectedCallback():

• @runopencode/stencil-signal - support for Preact's signal in Stencil. We wrote this because Lit just released support for signals and we asked our selves if this is possible for Stencil as well? Turns out, it is, but it surely relies on consistency of disconnectedCallback() invocation for each component using it.
• @runopencode/rx-stencil - we use RxJS with Stencil for years, very successfully, and we decided to compile some of our learnings into library which improves usage of RxJS with Stencil. Of course, auto-unsubscribing from observable and memory management with great DX depends on disconnectedCallback().

What Stencil also missing is implementation of context protocol (Lit has it) and it is described in fully here: #4431

There is a risk of Stencil team to decline proposal. And certainly, we do not intend to wait for Stencil team to implement it. This can be easily provided in user-land, why not? However, it is clear that consistency in invoking connectedCallback() and disconnectedCallback() are crucial to provide library of good quality and great DX.

We propose for Stencil Team to change compiler behaviour and always invoke lifecycle methods (at least connectedCallback() and disconnectedCallback()), of course, based on check if component instance has it (this will allow us to add/modify these methods with decorators).

If accepted, this would be beneficial for both Stencil and users, we would have reliable and consistent API/behaviour and therefore, we will be able to provide libraries in user-land of good quality and great DX.

Thank you for your time and consideration.