Closed 100phlecs closed 1 year ago
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:
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.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!
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 asturbo: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 youAre there plans to support this, or if not, what is your suggested strategy for dealing with event listeners on the global scope?