Symbols should be allowed as Event types.

[bicknellr]

This prevents the need to use a namespacing scheme or filter out similarly named events in the listeners themselves. Components generating particular events could instead expose symbols on their constructor (or other relevant object) to allow a user to listen to an event.

[annevk]

Sounds like a reasonable feature. We'd need interest from implementers and support in IDL. I'd also like to hear from framework developers and major websites if they'd use this.

[jcrben]

I'm not an implementor or a developer at a major website (just a small one!). Could you provide a brief example of how this would look in practice to understand how user-friendly it would be? I'd like to avoid using jQuery, but namespacing events is one of those things that the native event listening API doesn't seem to provide.

[annevk]

Something like

const eventType = Symbol(),
      event = new Event(eventType);
eventTarget.addEventListener(eventType, ...);

[bicknellr]

^ Yes, that's exactly it.

[annevk]

@benjamingr have there been requests for this in Node.js?

[benjamingr]

It's hard to say:

• EventTarget is very new and people mostly use it for AbortController, the only feature requests I got is to "add AbortSignal to more APIs" and provide tooling to make it more approachable and debuggable
• Node's EventEmitter already allows dispatching symbols for at least a few years. I can find some examples (e.g. https://github.com/webvalera96/currency-rates/blob/99a5e6caf36e17482faa064656b2d546707a9e7d/lib/HTTPClient.js#L31 ) that do this but it seems to be pretty rare and uncommon.

[matthewp]

This issue has come up with the web component community which wants to establish common event types but want to avoid name collisions, see: webcomponents-cg/community-protocols#19 (comment)

Allowing symbols as event types would resolve this issue for us. Is there still implementer interest in this idea?

[Westbrook]

Thanks for connecting these two conversations @matthewp 🙏

Very interested in what might be possible here!!

[benjamingr]

@domenic is this something that’s interesting for Chrome in terms of web components? If it is and there is implement interest I am happy to work on the spec once back from paternity leave.

(I am stuck on the AbortSignal stuff)

[domenic]

@mfreed7 is the best person to ask for web components stuff these days.

[mfreed7]

I think this sounds like a reasonable idea, and doesn't seem too hard to implement (modulo the details). I'm at least supportive enough to continue the discussion and get a more concrete proposal!

[benjamingr]

@mfreed7 I am happy to write the bikeshed - I think the proposal in this case is pretty straightforward:

• addEventListener accepts DOMString or Symbol for type.
• The Event constructor (as well as all subclasses implciitly) take a DOMString or Symbol for type.
• Places in the spec that reference the fact event names are strings get those references fixed.

The primary use case is enabling events without having possible naming collisions something like:

const myLibraryEvent = new Symbol('myLibrary');
const component = obtainElement(); // get any target
component.addEventListener(myLibraryEvent, myLibraryLogicForEvent);

// later, in other code, communicate without collisions
component.dispatchEvent(new Event(myLibraryEvent));

I can list use cases (it's mostly important in browsers where events propagate but also in Node.js and other EventTarget consumers)

---

Let me know what details you'd need to make a decision on this and if you think this is interesting enough to prototype I'll try to open a PR to this repo next week'ish.

[annevk]

Unless it got fixed in the intervening years, whatwg/webidl#377 (comment) will also need to be addressed in Web IDL I think. That can happen in parallel and by someone else, but it will need to be solved as this would be the first API to adopt symbols.

[benjamingr]

@annevk I actually have never contributed to webidl before and it's interesting learning experience for me to do so. I'm happy to lock time to take a stab next week if I will get guidance when I will (undoubtedly) get stuck like last time :)?

[annevk]

@benjamingr sounds great! The editors should be able to help you, yeah.

[mfreed7]

Let me know what details you'd need to make a decision on this and if you think this is interesting enough to prototype I'll try to open a PR to this repo next week'ish.

Just to be totally clear - I support this proposal, but I'll likely not be the first one to try to prototype it. Perhaps the Gecko or WebKit folks want to take a look first?

[jasnell]

Just weighing in, I'm +1 on supporting this both in Node.js and Cloudflare Workers. I'll wait to implement in either until the spec text is drafted up tho. I definitely think it's worthwhile.

[jasnell]

Just updating here. I did put together a quick prototype in Workers (not public, just local dev) to see if there would be any issues here and it all seems to just work rather nicely. Not a major (or even moderate) priority for us, of course, so no rush on getting it in, but I can't see anything that would/should prevent supporting this.