Closed ianwremmel closed 8 years ago
Do you mean adding methods to sync the api with that of EventEmitter, or extending EventEmitter itself? If it's the former that is being discussed in https://github.com/AmpersandJS/ampersand-events/issues/13. If it's the latter I don't know if it's a good idea as the browserifying of EventEmitter is quite large and unwieldy, last time I checked.
I mostly meant using EventEmitter as a base for ampersand-events. In my experience, EventEmitter is likely to end up in my projects because it's often a dependency of a dependency, so it seemed like a reasonable idea to converge them.
Alternatively, I'd be interested in something like AmpEvents.monkeyPatch(EventEmitter) to bring listenTo and possibly the "all" event to EventEmitter.
All that said, I completely understand if these requests are outside the scope of ampersand, I just wanted to float the idea before attempting to do it.
the API for ampersand-events was definitely a direct result of it being a fork of backbone's event API. I think if we add the methods needed to sync at least the methods with that of node's EventEmitter that will go a long way to reducing the mental effort of trying to work in both worlds, especially in the same project.
Gonna go ahead and close this for now, if someone has any good input on the matter feel free to weigh in or even reopen if you think it's warranted.
Follow up question: assuming #14 adds api compatibility with EventEmitter, can/does ampersand-events provide an object that can be used by util.inherits
and class X extends EventEmitter
as a drop in replacement? I could envision an aggressive webpack config that replaces require('events').EventEmitter
with require('ampersand-events').EventEmitter
.
Unless I'm mistaken this module itself would be the export. The idea is that require('ampersand-events')
would have function parity with require('events').EventEmitter
great, I'll give that a try. thanks!
Given that most projects of moderate size are likely to have a transitive dependency on events.EventEmitter, would it make sense to reimplement ampersand-events as an augmentation thereof? I imagine this would reduce both code size and cognitive load (dealing with subtly different event emitters is surprisingly problematic).