Re: [whatwg/dom] [Proposal] Add EventTarget.getEventListeners() (#412)

> I have less of a concern about `hasEventListeners(forEventType:string)` which could be useful for optimization purposes, which also has been proposed in this thread but wouldn't solve the original problem statement and should probably be pursued in a different thread, if desirable.

FWIW this would be enough yet important for my usecases as well.

As others noted, it's possible to implement such tracking yourself by tracking counts in `addEventListener`/`removeEventListener`, but it would be quite fragile.

For example, developer needs to carefully handle duplicates in the same way `addEventListener` does. E.g. `addEventListener('foo', foo); addEventListener('foo', foo);` are deduplicated but, say, `addEventListener('foo', foo); e.addEventListener('foo', foo, { capture: true });` are not.

Same applies to removing listeners - when user does `removeEventListener('foo', foo);` you want to only decrease count that matches `addEventListener('foo', foo)` but not `e.addEventListener('foo', foo, { capture: true })`. You also don't want to decrease counts when `removeEventListener` is a no-op because listener was previously removed.

Then, one also needs to correctly handle recently added `signal` option and remove listeners there (but only the "correct" ones as well).

While this is all possible to handle in userland, the amount of complexity of doing it there justifies exposing it as a DOM API instead, as browser already has all the necessary info to return answer for `hasEventListeners` much more efficiently and in a more future-proof manner.

-- 
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/412#issuecomment-886797676