You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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()
anddisconnectedCallback()
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()
anddisconnectedCallback()
) for two reasons: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()
anddisconnectedCallback()
:disconnectedCallback()
invocation for each component using it.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()
anddisconnectedCallback()
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()
anddisconnectedCallback()
), 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.
Beta Was this translation helpful? Give feedback.
All reactions