Async / Promise support?

[sfmskywalker]

Hi! I've been using your awesome library for a long time now and I love its ease of use!

Today I found the need to be able to have an async event handler. However, the event bus doesn't wait for the handler to complete of course since it doesn't handle promises.

Do you think it would be a straightforward-enough addition to check for promises and await them? If yes, I would be happy to provide a PR. Just need to know if you think it makes sense to have it.

[Logitao]

do you have an example? i'm curious

Today I found the need to be able to have an async event handler.

[sfmskywalker]

Sure!

I have the following use case:

1. I have a workflow designer library people use to design workflows.
2. This designer makes HTTP requests to the workflow server to GET & POST workflow definitions.
3. The workflow server requires a Bearer Token for authentication & authorization.
4. This means that the library user needs to be able to configure the Axios library (used by my library) with middleware.
5. To allow for that, I use your js-event-bus library to publish and event called e.g. "configure-http-client".
6. Here's what's async: the user's event handler gets the access token by invoking an HTTP request to /.auth/me which returns a JSON object containing the access token.

Performing the HTTP request in step 6 is an asynchronous call. Because it is important that the library code doesn't continue executing before the Axios HTTP client is fully configured (with middleware that sets a bearer token), here's what I need to do from my library's point of view (pseudo code):

var axiosConfig = {};
await eventBus.emit('configure-http-client', this, axiosConfig);
this.axiosClient = new axiosClient(axiosConfig);

For now I took your code and adapted it in its entirety so that for me there's no longer an option to invoke the event bus synchronously; I made the emit function async, which means I now always need to call await bus.emit(...).

That's fine for my purposes, but would break your users. So maybe introducing an emitAsync method, or perhaps even an entire clone called EventBusAsync or AsyncEventBus might be an option. This way, the user can explicitly choose whether they want a synchronous or asynchronous event bus.

[bcerati]

Hi @sfmskywalker,

I think it is a good idea to allow a user to add an async listener and be able to wait for the response when emitting the event.

I kinda like your idea to add an emitAsync function.

The only problem is that this functionality is not supported on IE 11 and this library has been made in such a way and code that it supports old browsers. But I was asking myself if I should not rewrite a 2.0 version of the library in a much modern code. So, we'd be able to add such functionalities.

[sfmskywalker]

Great! IMHO a 2.0 for the modern browser makes much sense. Users that need to support legacy browsers can of course keep using 1.x.

Should there be great demand for a 1.x version that also supports async, we could probably implement it using promises and then etc. instead of the modern async/await constructs. But I doubt there would be demand for that, given your library's age and nobody seems to have asked for it as of yet (that I can see from the issues).

If you want I'd be happy to contribute a 2.0 branch taking your code and rewrite it a little bit. But up to you. I can imagine it might be fun to do :)

[bcerati]

Indeed, I think we can ignore the 1.x branch. It can be added later if someone needs it, but I doubt it.

A new 2.0 version is the best option. But my plans was, before refactoring, writing some tests to be sure to not break anything (even for a 2.0 release).

It can take time to do tests and refactor. But I'll think about it in the next few weeks.

[sfmskywalker]

Makes perfect sense.

[sfmskywalker]

Hi @bcerati, hope all is well. Just checking in with you to see if you were able to take any stab at writing the tests. No worries if that's not the case, I know everyone is busy.

I'm currently working on a new version of my project during which I'm porting over some code from the previous version. So I figured, this may be a great opportunity to use a 2.0 version of js-event-bus 😃

[uglow]

@sfmskywalker Can I suggest another approach to this problem that does not require API changes?

What if you emit 2 events: configure-http-client-start and configure-http-client-end

[bcerati]

@uglow yes that'll do the trick ;)

I have rewritten all the lib using last JS features and typescript by default.

It's not released yet. It's currently in the main branch.

I'll add the feature requested in this issue in the release.

[RupertBarrow]

Hi @bcerati , can this be considered closed ?