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 = F.target; E; E = E.parentNode) {
            if (!E.className) {
                continue
            }
            var C = E.className.match(/\bl_([\w]+)\b/);
            if (!C) {
                continue
            }
            var D = B[C[1]];
            if (!D) {
                continue
            }
            if (A == "click") {
                $(E).blur();
                return D($(E), F) ? undefined : false
            } else {
                D($(E), F);
                return
            }
        }
        if (!window.gIphoneMode && A == "click") {
            popup.hide();
            $.closePopupMenu()
        }
    })
}

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.