A diabolical herd of pigs stole all of the front-end architecture from an innocent flock of birds and now they want it back!
Check out the series introduction post for a list of all the birds and their attack powers.
Blue Bird Attack
What Was Stolen by the Pigs?
The birds used to build their web applications with components having hard dependencies on each-other. They eventually started to learn to reduce tight coupling by introducing events and messages. Unfortunately the pigs, during their invasion, stole the birds’ observer secrets.
One of the blue birds has been tasked with taking back what has been stolen and restore loose coupling components.
In order to unpack the need for messages we will look at the following web application to search for movies from Netflix. We will uncover how this application was originally coded and then refactor along the way.
Tightly Coupled Code
The above code sample is a typical jQuery example that you can find across the internet. The snippet works, but there is a lot of different things happening all in the same place. You can find event handling, data retrieval, and data manipulation all mixed together. You can imagine that over time this code might continue to grow and grow and become more and more prone for errors.
Before we get too far, let’s take a side trip and look at what messages are and what types exist.
Types of Messages
An observer event is probably one that you are most used to if you are familiar with front-end web development. In relation to the DOM you can think of this as adding event handlers to an element. The element has a direct reference to the callbacks that will be invoked when the event type occurs.
A mediated event or message has become more common the last several years in front-end web development. The main idea here is that there is another entity that keeps track of publishing and subscribing of messages. The main difference between this and Observer events is that Mediated events aren’t tied directly to the subject that invoked it.
There are several libraries out there that facilitate mediated events. The following is a list of various libraries that you may want to choose from. My recommendation is that you look at Jim’s postal.js library.
- Ben Alman's (@cowboy) Tiny jQuery Pub/Sub library
- Peter Higgin's (@phiggins) pubsub.js library
- Jim Cowart's (@ifandelse) postal.js library ← Recommended
- Dustin Diaz's (@ded) reqwest library
- appendTo's (@appendTo) AmplifyJS Pub/Sub component
There is another type of event that is sort of a hybrid between observer and mediated. This type looks like a mediated event, but if you look hard enough there you could actually trace the origin of the event back to the original subject. A good example of this is jQuery’s delegated event model. Delegated events are great, but it is based on the concept of events bubbling up the DOM and therefore we can trace where it came from.
By the way, I don’t recommend using the
$._data() method as it is undocumented and therefore not guaranteed that it will be available in future versions of jQuery. It is an internal helper method that jQuery currently uses under the covers. However, I did want to show you that there is a way to poke around and get at information that the subscriber shouldn’t have in a real “mediated event”, which is why I’m calling it a hybrid event. Don’t get me wrong, I love jQuery’s delegated events. I just wanted to show how it is a hybrid of the two above concepts.
Which One Should Be Used?
That information is all fine and good, but what type of event/message should you be using and when? That is a great question and one that my friend Jim addressed in a recent post that he wrote. The following is a quote from his article…
"...use observer 'locally', inside a component, mediator 'remotely' between components. No matter what, be ready to use both in tandem.' --Jim Cowart
Jim recommends using observer events (jQuery’s
.on() method) when communicating within a module and to use mediated events (postal.js) when communicating between modules.
Another technique that Jim brings up in his article is to promote observer events into mediated events, which gives you the both of both worlds. He has some nice examples showing how that could look. I encourage you to take a look at his article referenced below in bold.
If you are interesting in more information about the above concepts you may consider looking through some of the following resources about events and messaging.
- Jim Cowart's (@ifandelse) Client-side Messaging Essentials article
- Rebecca Murphey's (@rmurphey) Loose Coupling with the pubsub Plugin screencast
Loosely Coupled Code
I was tempted to write the following code using Backbone.js or create constructor functions, but in order to keep it simple and convey the idea of messaging I tried to remove all of that. So, this probably isn’t what you’d have in your code-base, but hopefully it gets the point across.
space barto launch the Red Bird and you can also use the arrow keys. If it takes you too long to destroy the pigs you might want to consider pressing the
space barseveral times ;)
Using events and messages across your web application can help with communication. Events allow a component to communicate with itself and messages can enable other components to listen in without having a hard dependency.
There are many other front-end architecture techniques that have been stolen by the pigs. Tune in next time as the next Angry Bird takes its revenge! Dun, dun, daaaaaaa!