-
Notifications
You must be signed in to change notification settings - Fork 59
I noticed in the guides as well as the bind.ts tests that one cannot register actions to listen to global events.
What's the catalyst way of solving this?
For example, one may want to listen for a scroll event in the global scope, or a global event from a library like Turbo, such as turbo:before-visit@window to persist state changes between HTML pages that have the same custom element. I also use it to register window keybindings for when the custom element will not be in focus.
One could very well register it within the custom element with window.addEventListener -- but one of the main things attractive about Stimulus is that it handles event registration and destruction for you
Are there plans to support this, or if not, what is your suggested strategy for dealing with event listeners on the global scope?
All reactions
We wanted to avoid global event listeners as we find they often do more harm than good, for the most part. There seems to be two common classes of global event listeners:
- Using broad event delegation, e.g. listening for
clickon thewindowand checking thetarget. Event delegation is a good performance optimisation but can often be a premature one. Should a need arise for an element to have such an optimisation, it's probably good to state it explicitly. We don't want people to think it's the default. Adding a shorthand encourages this approach, we'd prefer to discourage it, as it comes with additional complexities (checking target, overly noisy callbacks, bubbling, propagation ordering,...
Replies: 1 comment
We wanted to avoid global event listeners as we find they often do more harm than good, for the most part. There seems to be two common classes of global event listeners:
- Using broad event delegation, e.g. listening for
clickon thewindowand checking thetarget. Event delegation is a good performance optimisation but can often be a premature one. Should a need arise for an element to have such an optimisation, it's probably good to state it explicitly. We don't want people to think it's the default. Adding a shorthand encourages this approach, we'd prefer to discourage it, as it comes with additional complexities (checking target, overly noisy callbacks, bubbling, propagation ordering, etc). - Global events like
scrollorresizewhich often come with performance issues. We wanted to avoid these and instead use better alternatives likeIntersectionObserver, orResizeObserver, which are more targeted and come with better performance characteristics. Again, adding a global event listener for this discourages the use of best patterns.
There's some validity to events that hang directly off of window or document, e.g. turbo events, but we have found these global events better belong to global code, not code controlled by a catalyst controller.
Hopefully this answers the question by providing justification for not adding these shorthands. If you want to discuss it further though, let's do so!