Is your feature request related to a problem? Please describe.
When in an async/await heavy project, EventEmitter can sometimes get a little in the way of a super smooth developer experience.
I would like to make this type of scenario simpler:
async setup() {
const server = http.createServer((req, res) => {});
return new Promise((resolve, reject) => {
server.listen();
server.on('listening', () => {
resolve();
});
});
}
There are 2 problems here:
- I have to manually set up a Promise.
- If in the middle of the
listening event handler, an exception is thrown, it will be an unhandled one.
Describe the solution you'd like
listening is an event you only care about once, so it would be nice to have emitter.once() like behavior but for promises.
async setup() {
const server = http.createServer((req, res) => {});
server.listen();
await server.once('listening');
}
I could image that the array of arguments sent to event listeners is also returned:
const [foo, bar] = await emitter.once('done');
Re-using the once method for this would avoid introducing a new method name that could conflict with existing emitters.
Please don't focus on the listening use-case too much, it is just one example (and this is not stackoverflow). It's the code pattern that I would like to discuss.
I would love to get peoples' input on this. Is this something you would want to see too? Or not, and why not? Is there a more elegant solution you can think of? Thanks.
Is your feature request related to a problem? Please describe.
When in an async/await heavy project, EventEmitter can sometimes get a little in the way of a super smooth developer experience.
I would like to make this type of scenario simpler:
There are 2 problems here:
listeningevent handler, an exception is thrown, it will be an unhandled one.Describe the solution you'd like
listeningis an event you only care about once, so it would be nice to haveemitter.once()like behavior but for promises.I could image that the array of arguments sent to event listeners is also returned:
Re-using the
oncemethod for this would avoid introducing a new method name that could conflict with existing emitters.Please don't focus on the
listeninguse-case too much, it is just one example (and this is not stackoverflow). It's the code pattern that I would like to discuss.I would love to get peoples' input on this. Is this something you would want to see too? Or not, and why not? Is there a more elegant solution you can think of? Thanks.