RFC - EventTarget API Enhancements

[benjamingr]

I've started working on an API enhancement for EventTarget that allows passing a signal to the options dictionary of addEventListener. As a side node I've prototyped the same for Node.js EventEmitter at #35877 (currently blocked on something V8 is working on).

This would let uses do the following:

// Does not yet work, suggested:
const ac = new AbortController();
let { signal } = ac;
const et = new EventTarget();
et.addEventListener('foo', (e) => {
  
}, { signal } );
ac.abort(); // removes the listener from the event target, same as et.removeEventListener('foo', thatFunctionReference)

In node land - this would be for example: unsubscribing from "message" and abort at the same time on multiple workers.

I wanted this feature for Node but I also find it very useful for browsers. I'm pretty clueless at this (Bikeshed etc) and Anne and Domenic have been helping me a ton with the spec work.

I personally think this positively impacts Node because:

• Node was in my mind when I started working on this
• I will happily do the technical part of implementing this in our EventTarget

That said: too many times in the past Node was an afterthought in open standards the project participates in and I want to gather feedback in case there are unforeseen negative consequences from our side.

So - is there anything this should do differently?

---

I would personally strongly prefer it if comments were given in this issue first to reduce the noise for WHATWG folks who have been helping me on this but really don't owe me anything.

Currently I have a spec draft ready at: whatwg/dom#919
Initial Chromium implementation (by chromium at whatwg/dom#911 (comment) )
Implementor interest by Firefox and Chromium.

[jasnell]

This is definitely interesting and useful. The spec will need to cover the full lifecycle including when the EventTarget unsubscribes from the signal but that's straightforward. Off the top of my head I can't think of any issues with this so I'd say go for it.