Feature request from @grorg. Original at https://github.com/whatwg/html/issues/2959.
@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 https://github.com/whatwg/dom/issues/208#issuecomment-316508778.) 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?
I don't understand the use case.
Why should the listener "care" about what addEventHandler options it was registered with?
The main case I can see is that it allows you to overload a listener so it can handle multiple (likely similar) scenarios.
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鈥檚 event listener list does not contain an event listener whose type is listener鈥檚 type, callback is listener鈥檚 callback, and capture is listener鈥檚 capture, then append listener to eventTarget鈥檚 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)
Thanks! At this point I'm somewhat inclined to close this issue unless someone makes a compelling case.
Most helpful comment
Thanks! At this point I'm somewhat inclined to close this issue unless someone makes a compelling case.