Proposal to add EventEmitter to core [ES7]

# aakarsh1997 (9 years ago)

I propose the inclusion of the node/io EventEmitter class[1] in core targeting ES7.

Reasoning: The .on/.emit model is very popular[2] in the ECMAScript land, and it suits the language a lot. We use events pretty much everywhere in the JS land. It makes sense for the standard EventEmitter class used commonly to be included in core. With ES6 classes, userland code classes extending[3] the EventEmitter class would be pretty common and useful even in environments like browsers.

Notes: I think the .once method from the node/io EventEmitter class could be left out from standard implementation mainly because we would rather use Promises there. Although it would also make sense to keep it in for further compatibility.

[1] iojs.org/api/events.html [2] search?l=JavaScript&q=eventemitter&ref=opensearch&type=Code [3] search?p=2&q=extends+eventemitter&ref=searchresults&type=Code&utf8=✓

# Andrea Giammarchi (9 years ago)

-1

not only node implemented EventEmitter without even reading what DOM had to offer before, I see whatever EventEmitter proposal would land in ES7 something related to lightweight traits, and not a class to extend. Extending EventEmitter without having the ability to extend something else looks like a poor choce to me, having a list of well known traits including the EventEmitter one would be better.

About current node implementation:

  1. it doesn't accept objects as listeners, a not so common but actully widely used practice on the WEB
  2. it does accept multiple times the same listener, a footgun on DOM-land
  3. it has a maximum amount of listeners per objects, a footgun on DOM-land
  4. it has an on method but not an off, not convenient on DOM where an app doesn't have same listeners forever due Ajax/client<->server interaction nature, I'd like a more consistent naming convention
  5. it exposes the ability to remove/retrieve listeners you don't own, again a footgun on DOM or anywhere the code is own by multiple libraries and authors

Just my 2 cents.

# Andrea Giammarchi (9 years ago)

Just to avoid misunderstanding ...

without even reading what DOM had to offer before

I meant it went out through a pragmatic approach with a non Events based emit model and few inconsistent choices regarding listeners in terms of both interface and the inability to interfere with non owned ... we need a better approach to EventListeners if it has to be implemented in core, something that could work in both client and server world.

Again my 2 cents

# Andrea Giammarchi (9 years ago)

Dan Peddle wrote me without replying to all about the limit that is configurable ... yes, I know that, but having no limit on core or a configurable limit different from 10 would make again the new thing inconsistent with current EventEmitter in node.

Again, I'd rather migrate to a new standard than bring EventEmitter as it is from node.js world to core ES.next, and also using traits.

# aakarsh1997 (9 years ago)

I'd rather migrate to a new standard than bring EventEmitter

If we can get an EventEmitter more suitable than the one node.js has to offer, I am all for it.

# Benjamin Gruenaum (9 years ago)

Note that when/if observables land we get an event-emitter mechanism in the language anyway.