Skip to content
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

Expose EventListenerOptions to the event listener when invoked #501

Closed
annevk opened this issue Aug 23, 2017 · 5 comments
Closed

Expose EventListenerOptions to the event listener when invoked #501

annevk opened this issue Aug 23, 2017 · 5 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: events

Comments

@annevk
Copy link
Member

annevk commented Aug 23, 2017

Feature request from @grorg. Original at whatwg/html#2959.

@annevk annevk added the needs implementer interest Moving the issue forward requires implementers to express interest label Aug 23, 2017
@annevk annevk added the addition/proposal New features or enhancements label Apr 11, 2019
@annevk
Copy link
Member Author

annevk commented Dec 8, 2020

@benjamingr @MattiasBuelens @jakearchibald @rbuckton @dmethvin I'm curious about your thoughts on this.

Apparently jQuery had this feature where you could identify the group a listener belonged to when the listener got invoked. (See #208 (comment).) Does something like that make sense for signals? Would that require the signal to be part of the key so you can register the same listener multiple times with different signals?

@benjamingr
Copy link
Member

I don't understand the use case.

Why should the listener "care" about what addEventHandler options it was registered with?

@annevk
Copy link
Member Author

annevk commented Dec 8, 2020

The main case I can see is that it allows you to overload a listener so it can handle multiple (likely similar) scenarios.

@benjamingr
Copy link
Member

Now that you have the signal argument and don't care about a reference to the listener for removeEventListener you can just register the "same" listener multiple times by wrapping it:

// Added multiple times, the anonymous functions are no longer an issue
// because we don't need a reference for removeEventListener
target.addEventListener('foo', (e) => myFn(e), { signal });
target.addEventListener('foo', (e) => myFn(e), { signal });

That said, doing what you describe is pretty easy? (and pretty small), just adding a signal to:

If eventTarget’s event listener list does not contain an event listener whose type is listener’s type, callback is listener’s callback, and capture is listener’s capture, then append listener to eventTarget’s event listener list.

I am not sure if it introduces complexity to browsers so I'm hesitant to offer to open a spec PR/WPTs if it's problematic for browsers to add that check when you add or remove a listener.

(A potential downside is that it would probably imply removeEventListener wouldn't work without passing the same signal in)

@annevk
Copy link
Member Author

annevk commented Dec 8, 2020

Thanks! At this point I'm somewhat inclined to close this issue unless someone makes a compelling case.

@annevk annevk closed this as completed Dec 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: events
Development

No branches or pull requests

2 participants