Removing event listeners through an identifier

[annevk]

Reportedly when writing components it would be convenient to be able to remove a whole swatch of event listeners through a common identifier, rather than having to enumerate all the specific types and callbacks.

I have discussed this a long time ago with @wycats I believe and more recently with @RByers. Now that addEventListener() supports a dictionary we could make this a reality. E.g.,

obj.addEventListener("click", ..., { class: "clicker" })
obj.addEventListener("focus", ..., { class: "clicker" })
obj.removeEventListener({class: "clicker" })

An alternative to overloading obj.removeEventListener() would be adding something like obj.removeEventListenerClass("clicker"), but that seems less extensible.

[dtapuska]

Couldn't addEventListener just return a handle object? That then you would call removeEventListener on in the future?

[annevk]

@dtapuska it's been a while, but I think the concern with that is having to manage the objects, similar to how the current setup requires holding references to the callback. Having a group feature (suggestion from Twitter as a better name for class) makes this kind of management much simpler. A single widget/component could register dozens of event listeners, all using the widget's name. And then when the widget is removed it simply removes all the event listeners with it, without having to keep track of objects and such.

[justsml]

I just think it's a little funny we (almost) have WebRTC, Asm.js, bg workers, sockets, etc... Yet DOM events slipped by, left to leak all over the place for years.

[jsen-]

please don't introduce more magic strings into the API.
I believe it would be much better to use Symbols or objects stored internally in a WeakMap than strings.

[domenic]

Allowing any value as the key (including a string) seems fine. You just later test with ===. Then people who want to use symbols or objects or whatever can do that, but most of us can just use strings like we're used to doing with jQuery.

[stuartpb]

Now that addEventListener() supports a dictionary

What's this now? Are we talking about the options object being added for passive event listeners?

[RByers]

What's this now? Are we talking about the options object being added for passive event listeners?

Yes, this.

[annevk]

@jsen- could you explain how the string would be magic? It's developer-provided.

[jsen-]

@annevk you're right, there's nothing magic about them, I just don't like using strings as identifiers.
I'd prefer something like obj.addEventListener(Obj.events.CLICK, ..., { class: Obj.eventClasses.CLICKER }), but that's for a different typed/untyped discussion.
I'm completely fine with @domenic's explanation

[adamdbradley]

Could addEventListener work similar to how setTimeout and clearTimeout works? For example, with setTimeout, setInterval, requestAnimationFrame, it's easier for apps to keep track of an id rather than a function which needs be called later on. For example:

var id = obj.addEventListener('click', ...);
document.clearEventListener(id);

Using an id rather than holding onto references to the handler could also reduce the potential for memory leaks.

What would be great is if the returned id could be global and not specific to the object the handler was added to. I used document.clearEventListener just for an example. Additionally, whatever removes the listener could accept one id, or an array of ids.

And to be clear, I also think @annevk's proposal is great, but why not both?

[RByers]

@adamdbradley @dtapuska asked that above and @annevk replied that he thought the group feature was strictly superior to returning a single handle. Any feedback on the differences between those two approaches to the problem?

I agree with Anne that using some group identifier (possibly an object, not just a string) is probably easier to manager than having to track an id. If you're going to track an ID anyway, you could just be tracking the callback in the same way. In fact, addEventListener could just return an object that contains the type, handler and capture values to be passed to removeEventListener later...

[adamdbradley]

@RByers Being able to group many event listeners through one common identifier sounds great, and I see the value of it because you're not tracking anything at all.

using some group identifier (possibly an object, not just a string) is probably easier

So to remove a group, would it have to strictly be the same object that was used in the addEventListener, or is it any object but with the same string value for class?

[annevk]

@adamdbradley the idea would be obj.addEventListener(type, callback, { group: anything }) and something like obj.removeEventListener({ group: anything }) to get rid of it. anything can be any ECMAScript value, including objects. We'd simply use === on the value passed to see whether it's the same.