`.emit ()` as an alias for `.trigger ()` about ampersand-events

[wraithgar]

What would be the benefit of this, outside a feeling of familiarity for someone used to EventEmitter?

I'm on the fence about this personally. Adding aliases is relatively easy to do, but they also add unneeded code and potential confusion in my own personal opinion. Totally willing to hear other ideas, or reasons why this helps (i.e. is there code that then becomes drop-in with this lib once we add x, y, or z?)

[latentflip]

I'm also +1 on @wraithgar's comment: increasing the api surface area, even if just with aliases, doesn't seem worth it to me without more compelling reasons.

[robbiewxyz]

In my case, I've just been switching my Node data structures from mixing in EventEmitter to extending AmpersandState, and being able to drop in (instead of requiring s/emit/trigger) would be nice.

But yea, I'm split the same way with the potential confusion. It's up to you whether this's worth doing.

[latentflip]

It's up to you whether this's worth doing—I'm not even sure if using Ampersand on the server is a use case you support.

Where possible we've made as much of ampersand run in node as possible.

FWIW you could create a base-state.js in your app, (often in frontend apps you have one of those anyway for various reasons), that looks like:

var State = require('ampersand-state');
var BaseState = State.extend({});

BaseState.prototype.emit = BaseState.prototype.trigger;
//... etc
module.exports = BaseState;

and import that where you want eventemitter like methods and it'll just work:

http://esnextb.in/?gist=2b4714ccfda21e62e5f2