Use EventTarget interface for events

[caspervonb]

No description provided.

[TimothyGu]

It would be a LOT of work to convert everything over. I also kinda like the "on" and "once" terminology.

[benjamingr]

ayo can support observables and Symbol.observable when those make Stage 3, right now it's all still stage 1 and they're figuring out the stuff themselves.

[ghost]

for others who aren't aware of these things:

• EventTarget, the interface has addEventListener and removeEventListener (is this what @caspervonb is referring to?)
• TC-39 proposal for Observables (not sure if that's what @benjamingr is referring to)

It doesn't sound like it would be a stretch to support EventTarget interface as well, but I haven't hacked on this codebase before.

[addaleax]

@omouse If you want to try and put a PR together for EventTarget: I think that would be so awesome?? It seems sensible to me to do that. If you need and help, ask here, or in our Discord (#12 (comment)), and we’ll answer any questions on how to get you set up / how to put the PR together!

There’s also something in our CONTRIBUTING.md, where a lot obviously still refers to Node.js, but it should still be doable to work with it

[bmeck]

We talked a bit about this at the last TC39 meeting and the general consensus is that if you support EventTarget you should support the DOMExceptions it produces. Please try and conform to that if possible. You can read some of the discussion in the meeting notes.

[ghost]

@addaleax the code would go into lib/events.js yah?

thanks for the meeting notes @bmeck it looks like the relevant parts are:

DD: Whatever cancellation/abort API TC39 produces, it must be compatible with https://dom.spec.whatwg.org/#interface-abortcontroller, since Chrome and Firefox are shipping that soon. The requirements are:

• Any code written against the existing AbortSignal/AbortController API must not break or change semantics. Anything produced by TC39 must be compatibly layered on top.
• We are not interested in shipping two separate aborting mechanisms (e.g., AbortController for the web platform plus a TC39-specific CancellationToken).
• We must reuse the same eventing mechanism as the rest of the platform: EventTarget
• We must be extensible with other events, for other signals we plan to add to fetch (e.g. progress)
• We must be extensible with other controls, for other controls we plan to add to fetch (e.g. changing priority)
• We should reuse the exception type used by other aborts on the web platform, i.e. DOMException "AbortError". This could potentially be changed if it proves to be web-compatible (e.g., perhaps another exception with .name === "AbortError") by the time TC39 gets to stage 3.

and this:

BT: Cancelation is something that is very important, and while this proposal is just API, I imagine that ECMA will grow to support other async operations that needs cancelation tokens. How do we make it interoperable, I don't know, but we should pursue looking for a solution and solve, regardless of the host. In some fashion, TC39 must support a cancellation primitive, since our async APIs are only going to grow (e.g. dynamic import). If we don't want to change the AbortController API, then TC39 needs to bring the AbortController API into this standards process. I worry that we're leading with the browser and not making sure this is a primitive that works with different host environments.

also this:

YK: (to BF) Would you object to add EventTarget API?

BF: Node OK with the EventTarget API but not the exact .prototype inheritance chain.

BT: It seems like a red flag that AbortController (extending EventTarget) may not necessarily be compatible with Node.

seems like a lot of discussion on how abort/cancellation work, and some talk on the inheritance chain/prototype:

MM: ...I think it's worth investigating whether we could achieve interop by taking a lesson from Promise assimilation, rather than requiring things like instanceof EventTarget.

So I guess that's the big question and mirrors my question to @addaleax about where the api should be updated to support this interface. Should it be EventEmitter? Should it be a new prototype EventTarget that re-uses whatever we have in EventEmitter?

[medikoo]

EventTarget is quite DOM specific (with it's capturing and bubbling phases etc.), I wouldn't mix it with simple concept of EventEmitter that's in Node.js.
While similar (as both replicate same pattern) they're different and dedicated for quite different contexts.

[ghost]

@medikoo EventTarget as a separate prototype/class then? Sounds good to me.

@caspervonb do you have a specific example or context that you'd like to use EventTarget in?