Is a promise-aware eventing system desirable?

Question

I'm fully aware that Promises and eventing are both ways to do asynchronous programming, and you can choose either one for a given project. However, in practice, the code base I'm working with is large and we use many 3rd party libraries that handles asynchronicity differently so mixing the two approaches together are unavoidable (and often with disastrous effect).

Too many times I've seen people fire an event and then do more stuff after it, while expecting the event handlers to have fully finished. Unfortunately some event handlers will start a chain of Promises but there is no way for the event source to know when that chain is resolved.

In theory, the proper way to do async programming with pure eventing alone would have been for the event handler to raise an "event_x_completed" event but that assumes that there is always exactly one event handler for the original "event_x" (unless you want the code to get ugly. See example at the bottom). In UI programming, we often should not care how many listeners there are. E.g. one user action could raise an event to trigger any number of UI components to refresh themselves.

Also, depending how it is done, it could create a tight coupling between the event source and the event listeners, which invalidates a big strength to use event in the first place. My project has a complicated UI so an event source can't/shouldn't care how many handlers are listening to an event.

I think it would be great to have an eventing system that tests whether each handler returns a Promise (or then-able object), and fire("event_x") should return Promise.all(all_promises_from_handlers) to the event source.

I've looked around (maybe not hard enough) and I don't see anyone talking about a Promise-aware eventing system. Do people have the same problem and how is it handled?

Edit for concrete example:

The originator of "SAVE_PRESSED" doesn't care how many handlers there are, it only cares that they are all completed. I think it would be immensely useful to be able to do this:

function saveClicked() {
    saveButton.disable();
    EventManager.raise("SAVE_PRESSED").then(function() {
        saveButton.enable();
    });
}

With pure event, of course we could loop through all the listeners and do this instead:

function saveClicked() {
    saveButton.disable();
    var listeners = EventManager.getListeners("SAVE_PRESSED"); // array
    EventManager.raise("SAVE_PRESSED");
    EventManager.listen("SAVE_COMPLETED", function(listener_id) {
        var index = listeners.indexOf(listener_id);
        listeners = listeners.splice(index, 1);
        if (listeners.length === 0) {
            saveButton.enable();
            // AND -- unregister this function as a handler for SAVE_COMPLETED
        }
    });
}

What I don't like about this:

• The code is longer and it's not even complete and doesn't have proper error handling.
• This depends on the listeners raising a "*_COMPLETED" event.
  • If this is not always true or required, then each listener needs to indicate whether they are async (will raise a COMPLETED event) or not. This is additional configuration to maintain.
  • And instead of EventManager.getListeners("SAVE_PRESSED"), we call EventManager.getAsyncListeners("SAVE_PRESSED");
• This code / functionality should be provided by the EventManager
  • If it is moved into the EventManager, then "*_COMPLETED" events are essentially very special.

In a promise-aware event system, the handlers can tell the system that they are async by simply returning a then-able object.

Answer 1

A promise aware eventing system can help you build graceful solutions to complex problems. However, I think it is worth choosing an existing framework rather than creating your own.

The (JavaScript) framework I have used most is Dojo and it has a robust collection of event handling code.

It includes chaining events as mentioned, then, when and all. all is nice because it will wait for a set of promises to resolve before proceeding.

I suggest you run through some of the tutorials at their site to see if it will serve your needs well.

Answer 2

In theory, the proper way to do async programming with pure eventing alone would have been for the event handler to raise an "event_x_completed" event but that assumes that there is always exactly one event handler for the original "event_x". In UI programming, we can't make that assumption. E.g. one user action could raise an event to trigger any number of UI components to refresh themselves.

Er no. You absolutely do not need to assume that there is always exactly one event handler.

There are exactly as many event handlers as you want there to be. An event handler registers itself in a list of handlers of that event.

event_x_completed(x_id) tells me exactly which event has completed. Not simply that it a type x event but it was exactly the x that I was waiting for.

It's confusing to mix two different paradigms but be sure you know to use both before you assume they are completely incompatible.