Repository navigation
Add async emit methods to EventEmitter #18646
Description
-
Version:
v8.9.4 -
Platform:
Darwin pumba-5.local 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64 -
Subsystem:
events
https://nodejs.org/api/events.html#events_asynchronous_vs_synchronous instructs users to cause asynchronous event execution in the event handlers by using setImmediate or process.nextTick, which means that, when using EventEmitter#emit, asynchronous event handling is left to clients, and the EventEmitter has no control over whether an event is handled asynchronously or synchronously. In cases where the EventEmitter is sensitive to performance, the EventEmitter itself can dictate the event emission is asynchronous via code similar to the following:
class MyClass extends EventEmitter {
// ...
doSomething() {
process.nextTick(() => this.emit.bind(this).call('myEvent', {foo:'bar'}))
// ...
}
}
The emit line above could be replaced by something convenient like
this.emitNextTick('myEvent', {foo:'bar'})
// or
this.emitImmediate('myEvent', {foo:'bar'})
or, even more conveniently,
this.emitAsync('myEvent', {foo:'bar'})
which uses either setImmediate or process.nextTick according to the current environment.
Activity
bnoordhuis commentedon Feb 15, 2018
Asynchronous emit has been discussed as early as 2010 or 2011. It never happened and I wouldn't expect it to happen now. Ultimately (and as you mention), it's a convenience, not a necessity.
apapirovski commentedon Apr 14, 2018
There doesn't seem to be much movement or interest in this feature so I'll close this out but feel free to re-open if you feel strongly about including this in core and/or plan to work on a PR. I tend to agree that it's a convenience that can be easily implemented either in a user-land module or even on a per project basis (it's a 1 liner).
macedd commentedon Mar 13, 2019
This is how I solved the async emitter https://github.com/thiagof/async-event-emitter