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
{{ message }}
Repository navigation
Stimulus action @window or @document equilvalent? #311
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?
We wanted to avoid global event listeners as we find they do more harm than good, for the most part. There seems to be two classes of global event listeners:
Using broad event delegation, e.g. listening for click on the window and checking the target. 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.
Global events like scroll, resize which often come with performance issues. We wanted to avoid these and instead use better alternatives like IntersectionObserver, or ResizeObserver, 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.
I'll close this issue as hopefully this explains the justification for avoiding these shorthands. If you want to discuss it further though, let's do so!
Activity
keithamus commentedon May 10, 2023
We wanted to avoid global event listeners as we find they do more harm than good, for the most part. There seems to be two classes of global event listeners:
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.scroll,resizewhich 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
windowordocument, e.g.turboevents, but we have found these global events better belong to global code, not code controlled by a catalyst controller.I'll close this issue as hopefully this explains the justification for avoiding these shorthands. If you want to discuss it further though, let's do so!