Re: [whatwg/dom] Removing event listeners through an identifier (#208)

>From a jQuery-experience point of view this seems like a good feature for what I've seen to be the most common use of namespaces, which is removing a group of event listeners for a plugin. Although there's a lot of painful logic to deal with multiple namespaces, I doubt it's used that often. We don't have any way to collect stats on that so I could be wrong.

The PR says that the `group` can be either a `Symbol`, string, or array of those. That should map fine to the multiple-namespace-string approach used by jQuery. A jQuery namespace of `.a.b.c` would equate to `addEventListener` as `group: [ "a", "b", "c" ]` .

However, note that jQuery does more with namespaces than just adding or removing listeners. It exposes [`event.namespace`](https://api.jquery.com/event.namespace/) as a string; the example above would get `".a.b.c"` for a value. That means the event listener can change its behavior based on namespace. Programmatic event triggering allow namespaces so `.trigger("click.a")` calls a jQuery listener attached with `"click.a.b.c"` but `.trigger("click.c.d")` would not.

I doubt jQuery could use this new event interface unless we deprecated and removed the existing namespace features, they _are_ used in the wild. However, I don't think jQuery's ability to adopt the interface in its own codebase should be the litmus test for new features in the standard. It _would_ be good to check with other frameworks and libraries to find out whether they could take advantage of this feature. They may have similar reasons why it doesn't quite match their needs.

> The `handleEvent` pattern is the solution to most problems developers have, they just don't know/use this pattern because jQuery core at John time probably didn't use or know about such pattern so it didn't gain much attention.

I'm pretty sure most of the jQuery team was aware of this pattern. However, `addEventListener()` wasn't supported by IE 6/7/8 so it was even in play until those browsers died off. At that point, jQuery had a whole set of infrastructure in place to deal with various browser inadequacies and external code now depends on that behavior. (One example, browser devtools grope into jQuery event internals so they can see the user's actual event listener instead of jQuery's event multiplexer; we can't unexpose them now.) Rewriting a fundamental part of jQuery without breaking the ecosystem is nearly impossible. 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/208#issuecomment-316508778