Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stimulus action @window or @document equilvalent? #311

Closed
100phlecs opened this issue May 6, 2023 · 1 comment
Closed

Stimulus action @window or @document equilvalent? #311

100phlecs opened this issue May 6, 2023 · 1 comment

Comments

@100phlecs
Copy link

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?

@keithamus
Copy link
Member

keithamus commented 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:

  • 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!

@github github locked and limited conversation to collaborators May 10, 2023
@keithamus keithamus converted this issue into discussion #312 May 10, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants