Open robinplace opened 8 years ago
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?)
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.
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.
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:
What do you think about adding
.emit ()
as an alias for.trigger ()
. This would allow it to have a signature very similar to NodeJS'sEventEmitter
class which would be nice for server-side code.Along with this might come aliasing
.removeListener ()
to.off ()
.What do you &yet-ers think about this? Is this kind of uniformity worth doing for you?
P.S. I'm LOVING AmpersandJS, using it everywhere from my API on Node to the app in the browser. Keep up the good work!