-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.emit ()
as an alias for .trigger ()
#13
Comments
What would be the benefit of this, outside a feeling of familiarity for someone used to 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 But yea, I'm split the same way with the potential confusion. It's up to you whether this's worth doing. |
Where possible we've made as much of ampersand run in node as possible. FWIW you could create a
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!
The text was updated successfully, but these errors were encountered: