jacomyal / emmett

A custom event emitter for Node.js and the browser

👋 Hello!

I'm Alexis Jacomy, aka @jacomyal, a Front-End Engineer specialized in graphical rendering and data visualization.

I'm part of the innovative team at OuestWare, an agency based in Nantes, France. We specialize in developing web applications for data exploration.

As a part of my work at OuestWare, I'm the main developer and maintainer of sigma.js, an open-source library focused on efficiently displaying networks within web pages.

We also develop:

• Gephi Lite a web-based, lighter version of Gephi, the networks visualization and exploration software;
• Retina, a web application to share graph visualizations online.

Finally, I sometimes write on 🐘 Mastodon or on 🗒 OuestWare's blog.

Thank you for visiting, and let's connect!

emmett's Issues

Decide whether absent data should be {} or undefined

Cleaning up offing process

Support Symbols as event names.

What it says in the description :)

Fire handlers in the emitter's scope.

Cut sort on event sourcing possibilities

Once in combination with off fires constantly

Please see #19 for a test case and more details.

Kill: reminder to check whether silence is the good option

#off(handler) fails with symbols

const Emitter = require("emmett");
const emitter = new Emitter();
const event = Symbol("myEvent");

let count = 0;
const handler = function() { count++; }

emitter.on(event, handler);
emitter.off(handler);
emitter.emit(event);

console.log("Count:", count);

Expected result:

Should log Count: 0

Actual result:

Should log Count: 1

Method to retrieve listeners

http://nodejs.org/api/events.html#events_emitter_listeners_event

Would be nicer than counting _handlers and _handlersAll.

Support for wildcards in event listening?

This could be insanely useful at times:

ee.on('ns:*', fn);

Sort handlers (only in worst cases)

New emit polymorphism

e.emit({eventName1: data1, eventName2: data2});

Event names enumerator

Can we add some option to enumerate all possible event names?

This is valuable because:

1. users will have an official place to check for possible emit options
2. we get errors when event name is mistyped

Something like:

import Emmett from "emmett";

let emitter = new Emmett([
  "scale.mouseDown"
]);

emitter.on("scale.mouseDown", (data) => {
  console.log("scale.mouseDown!");
});

emitter.emit("scale.mouseDown"); // CONSOLE.LOG
emitter.emit("scale.mouseUp"); // ERROR!

I don't know how it's better to adopt this to custom emitters (inheritance) but there are some ways...

Should the minified version served along the npm package?

#emit breaks with symbols and complex handlers

const Emitter = require("emmett");
const emitter = new Emitter();

emitter.on(/some pattern/, function() {});
emitter.emit(Symbol("myEvent"));

console.log("All good.");

Expected result:

Should log All good.

Actual result:

Throws TypeError: event.search is not a function

Implement .off variant 3

Distinguish handlers and handler functions in the code

Add a once method to the emitter and the binders.

Documentation

Emitter.off('event') polymorphism.

Symbol-keys are ignored when using pair events

Hi there,

just noticed you've added Symbol support. There is one bug though when using pair events like this:

myEmitter.on({
  myEvent1: function(e) {  },
  myEvent2: function(e) {  }
});

Since Symbols can not be enumerated with for ... in or Object.keys(events).on they are just being ignored in such cases.

Sorry, I don't have time for a proper PR, but here is a possible solution

// instead of using `for ... in` you can process each key type individually

// Symbol-keys
Object.getOwnPropertySymbols(events).forEach(function(event){
     // this.on/off/etc....
});

// String-keys
Object.getOwnPropertyNames(events).forEach(function(event){
     // this.on/off/etc....
});

Seems to fail when trying to emit an invalid argument

Maybe some type checking and a better error can be created.