Wednesday, September 23, 2009

JavaScript: jQuery Event Handling in FriendFeed

My buddy Andreas Schobel and I both use jQuery. He was mentioning to me that his page was getting too big, and setting up all the event handlers was taking too long. He noticed that FriendFeed also uses jQuery but doesn't have this problem. In fact, he couldn't figure out how FriendFeed's click handlers even worked. We decided to investigate.

We started investigating this file. It was minimized, so we ran it through the Javascript Beautifier. This reindents the code. However, it can't deduce the original variable names for local variables. That makes understanding the code a little harder, but it's still possible.

We started looking for instances of the word "click". It looked like the file contained jQuery plugins that made use of the click function, but the main app didn't. We saw this line:
var clickHandlers = {};
And a bunch of functions like:
clickHandlers.expandcomments = function (A) {...};
However, we couldn't find any place that was actually using clickHandlers. Finally, I started looking for just the word "Handlers", and I came across this:
function bindEvents(A) {
var B = window[A + "Handlers"];
$("body")[A](function (F) {
if (A == "click" && handleFBClick(F)) {
return false
for (var E =; E; E = E.parentNode) {
if (!E.className) {
var C = E.className.match(/\bl_([\w]+)\b/);
if (!C) {
var D = B[C[1]];
if (!D) {
if (A == "click") {
return D($(E), F) ? undefined : false
} else {
D($(E), F);
if (!window.gIphoneMode && A == "click") {
It took a little longer to figure out what it meant.

Events are allowed to propagate all the way up to the body. The body has handlers for many types of events such as "click", but they all point to the same event handler function, which is nested anonymously inside bindEvents.

Let's suppose a JavaScript link is clicked. The event will propagate up to the body tag which will try to handle it. The class name for the link is inspected. If it is something like "l_expandcomments", and clickHandlers has a member called expandcomments, then that function is called. There is special code to a) stop further event propagation unless appropriate b) stop the user from double clicking c) do something special for iPhone users.

Hence, they can connect an HTML element with a JavaScript handler just by adding a class such as "l_expandcomments" and adding an "expandcomments" function to clickHandlers. That's convenient and clever. JavaScript's malleable (almost chaotic) nature reminds me more and more of Lisp (which I've been saying for years). Going back to my buddy's original problem, this approach seems like a viable way to reduce the event handler setup time. I wonder what initially lead them to take this approach.


Josh Powell said...

This is called event delegation, they are probably using jQuery's .live() method. Good articles on this at

Shannon -jj Behrens said...

Thanks, Josh.

Eugene said...

Andreas showed me this article, and it's a good approach, with one caveat. Instead of using the CSS Class to control behavior, I'd use a custom attribute added to the elements I want to handle.

Hijacking the CSS Class to control Javascript functionality can cause maintainability hassles if you ever want to restructure your CSS.

Shannon -jj Behrens said...

I guess to each his own. I know a lot of people really dislike the idea of using non-standard attributes. Doesn't that break validation? I have some CSS classes used for JavaScript, and some used for styling. Since you can use multiple classes on the same element, e.g. class="handle-clicks make-purty", I don't see the problem.