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

Hi all. A bit surprised at some of these questions, @smaug----.

> So is there an API proposal here?

Yes. It's the one discussed at length in this thread, and concretized by PR #469. I noted you commented over there, so I'm a bit confused why you state here you're unable to find the API proposal.

> Do we know it is such which script libraries would use, or would they still just have some their own API on top of that?

Yes; jQuery is a prime candidate, since that is where this feature originates. As are all the frameworks built on top of it. In general this feature is highly desired by frameworks since they like to be able to manage their event listeners en-masse. Right now they are having to keep a side-table of function references so they can remove them later. This is especially the case for custom elements, which are like little self-contained frameworks themselves.

See also #412; although this proposal doesn't subsume that one, it provides a less-dangerous subset that addresses many of the same use cases (e.g. allowing coordination via disparate parts of the code/different libraries as long as they agree on the same `group` string).

> Before adding random new features to add/removeEventListener, I think we should think a bit more what all features we expect would be commonly used and would improve the platform.

Indeed. This is part of that effort, going back years; there's actually been a lot of thought about this, which you can see from the various discussions here and, back in the day, on www-dom. (It's not "random".) Removing event listeneres by group is a top candidate, as is event delegation (#215), based on patterns that a majority of popular libraries end up inventing independently. The `once` option is another example, which we've successfully added, to great applause from web developers.

> Also, making APis more complicated makes implementations slower - perhaps not much per new feature, but over time when more features are added...

I certainly understand that everything has a cost. I'm a bit surprised you think I need to be reminded of that. Furthermore, as I explain a bit more below, I think this will overall increase the speed of web pages.

@cdumez

> Seems like something the JS libraries could easily implement so I am not sure its is worth complicating the engine. That said, I don't think this would be a lot of work to implement.

Yes, this is definitely not a new primitive. This is part of a different effort, to make the platform more ergonomic based on the feedback we've gotten over the years; we've provided the primitives, seen what people have built, and now it's time to bring that knowledge back into the platform.

It's more along the lines of the existing `once` option, or the append()/prepend()/remove() operations. These all  make the "raw DOM" API more usable, so people stop having to download large libraries to wrap it. (In our experience, these extra libraries cause much more slowness than the cost of a bit of extra processing in built-in APIs.)

The other point is that this particular proposal fits well in the effort/reward tradeoff, as you point out. Personally I think this and #467 are a slam dunk in that regard. #215 is less clear; it'll likely be more effort to implement, but also higher reward. We'll be able to evaluate the actual tradeoff there better once we have a spec, and possibly a prototype in Blink.

-- 
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-310909898