Currently, I’m working on an application that uses a lot of global events which I lovingly call the “invoke global search in your editor to find anything” architecture. Long story short, there are a lot of pieces of code loaded dynamically and I wanted a way to those pieces to hook together fairly easily.

Yes, I know there are better ways to do this… this is not a discussion about that.

Anyway, I have a global events object in it’s own module that looks something like:

I found myself using a common pattern of wanting to have an event handler call a callback when it was done processing. This way things were nice and asynchronous.

Easy enough. This pattern worked great and I used it throughout my app.

However, I ran into an issue. I had an array of data that I needed to process via event. And, being a good Javascript developer, wanted to make sure to handle asynchronous issues correctly. In my case, I wanted to make all the events were processed before continuing on to the next thing.

So, of course, it’s time to bring in promises here. In fact, I think I wanted to use promises for all of my event handlers instead of just the generic callbacks. It gives me a cleaner API to work with and is just more flexible if we need to start chaining things together.

Whenever promises are used, it’s very easy to fall into the deferred anti-pattern. Of course, everyone has been guilty of doing this one time or another when it’s a one-off kind of situation. But, I was planning on doing this throughout my application, so I needed to come up with something cleaner.

Lately, I’ve been using Bluebird as my promises library, especially in node. While digging through their documentation, I started to see that pretty much every example was trying to wrap the same type of API I was using. Basically, it was example after example of wrapping generic node.js methods into promises automatically.

Hey! I’m using generic node.js methods! This was made for me, right?

Since no one was around to answer my rhetorical question, I gave this modification to my global event object a try:

Cool. Now when I fire an event, I have a much cleaner API to deal with. There is no change to make on my event handler. In fact, no changes need to be made at all unless I want to use a promise instead of basic callback as they become interchangeable now. Here is the same code as above, except now I added a second call using the new Promises API.

The second way is much prettier if you ask me.

Now, here comes the best part. I can now easily handle my multiple events in a nice clean way that allows me to wait on them all the finish processing before moving on to the next piece of functionality.

Ted Kulp

Ted Kulp is a professional developer, author and technologist with over 15 years of experience from the suburbs of Philadelphia. In 2004, he created the popular content management system, CMS Made Simple and continued to run the project for over 8 years. These days, he makes his living from writing Javascript full-time, writing books, and hacking on open source.

More Posts - Twitter - Facebook - LinkedIn - GitHub

Notice: mc4wp_form is deprecated since version Mailchimp for WordPress v3.0! Use mc4wp_show_form instead. in /var/www/html/wp-includes/functions.php on line 4440

Find this interesting?

Sign up for my newsletter for more interesting content.