Eventing Library

Shh! Quiet! This is a library!

Welcome everyone. If you'll keep your voices down, I'll show you how we can give our JavaScript objects the ability to build their own eventing libraries. What would this mean exactly? It would mean the object in question could file specified functions under an event name. If this event were ever triggered, these functions would then be executed.

Hmm. This sounds a lot like an object method. Why would we go to all this extra effort when we could just write an object method and then call that method?

Consider a situation in which, given certain conditions, you might want to add additional lines of code to an object's method. We can do this by reassigning the object's method to a function which calls its old method and then executes any additional lines of code. This is a bit clunky. An object with an eventing library can dynamically add additional code to any of its pre-existing events.

If you've worked with jQuery this idea should be pretty familiar. Any jQuery object can listen for events from the user's keyboard or mouse, and we can define what behaviors that object has (if any) for those events using .on().

Consider sleepySlacker, an employee taking a nap on the job. The sleepySlacker object magically already has the ability to add events (using .on) and execute those events (using .trigger).

sleepySlacker has an event called "wake-up", that, when triggered, will log "huh? what?" This is all fine and dandy, but imagine at some later time the boss walks into the room. It's going to look pretty bad if sleepySlacker just says "huh? what?" They should probably cover for themselves; they were only resting their eyes after all...

Now when someone wakes the sleepySlacker, their previous behavior will execute (logging "huh? what?"), but it will then be followed by the new behavior (logging "i wasn't sleeping i swear!").

You might be thinking this is a pretty trivial example. That's pretty rude, but you're right. It is. The important take-away is that an eventing library is very powerful for dealing with asynchronous situations. We don't know when sleepySlacker's boss is going to walk into the room, but when they do we're able to adjust sleepySlacker's behavior upon being awakened accordingly.

Now that you're convinced, let's go over how to implement a function which will add these magical "on" and "trigger" methods to any object. We'll call this function eventSystemDecorator.

Here we have our general objectives outlined. eventSystemDecorator should take in an object and return that object with "on" and "trigger" methods added. The "on" method should allow us to associate a callback function of our choosing with an event name of our choosing. Multiple callback functions should be able to be associated with the same event. The "trigger" method should be able to locate all the callbacks associated with a given event and execute all of them.

Let's start with "on":

If the event does not already exist, we add that event as a property on obj. We want to be able to possibly store multiple callbacks for this event in the future, so we initiate this event's value as an array with the callback as its only member. If we had chosen to simply assign the event's value to the callback directly (as in obj[event] = callback), any time we wanted to add a new callback to the same event, we'd be overwriting the previous callback. If the event DOES exist, we simply add the current callback to that event's existing collection of callbacks.

Now for "trigger":

First we check to see whether the object has this event. If it doesn't we don't want to do anything. If it does, we iterate through all callback functions associated with this event, calling each passing in the arguments passed to "trigger".

All we have left to do is return the object to which we've added these useful methods. Our object can now add and respond to events! Thanks for reading everybody!