Lines 167 to 176 in 69193ca
The above code executes the emit
method without any await. The way this library is currently implemented, this is no problem. But for my project I derived a class from emittery where I made an override of emit
to yield the control back to the event loop. I did this to make every emit truely async and prevent any event from being executed synchronously. This might be a good feature for emittery too, but that is beside the point here. Here is my implementation:
override async emit<Name extends DatalessEventNames<EventData>>(eventName: Name): Promise<void>;
override async emit<Name extends keyof EventData>(eventName: Name, eventData: EventData[Name]): Promise<void>;
override async emit(eventName: unknown, eventData?: unknown): Promise<void> {
log.info('emit', eventName);
}
This lead to a lot of errors from this line, because the canEmitMetaEvents
flag is already reset again:
Line 351 in 69193ca
This issue could be solved by using the suggested code in this comment: #97 (comment)
Yup. Or we can have a special function that emits the meta events on a given emitter instance. Something like this.
async function emitMetaEvent(emitter, event, data) { metaEventsAllowed = true await emitter.emit(event, data) metaEventsAllowed = false }The only benefit of this function over the callback approach is, we will not end up creating too many anonymous functions.
if (!isMetaEvent(eventName)) { emitMetaEvent(this, listenerAdded, {eventName, listener}) }
Pay now to fund the work behind this issue.
Get updates on progress being made.
Maintainer is rewarded once the issue is completed.
You're funding impactful open source efforts
You want to contribute to this effort
You want to get funding like this too