Object-Oriented Event Listening through Partial Application in JavaScript

Appreciating the need for method references

The following code does not do what the programmer intended it to:

function GreetingButton(greeting) {
    this.greeting = greeting;
    this.element = document.createElement("button");
    this.element.appendChild(document.createTextNode("Receive Greeting"));
    this.element.onclick = this.greet;
}

GreetingButton.prototype.greet = function () {
    alert(this.greeting);
};

onload = function () {
    gb = new GreetingButton("Hello!");
    document.body.appendChild(gb.element);
    gb.greet();
};

When the button labelled Receive Greeting is clicked, the string undefined will be alerted instead of the intended Hello!. The reason is that this in the expression alert(this.greeting) will refer to the HTML button that was clicked—notgb, the GreetingButton object.

function f() { alert(this); };

var foo = "foo";
var bar = "bar";
foo.f = bar.f = f;

To side-step the problem, you might consider doing this:

function GreetingButton(greeting) {
    this.greeting = greeting;
    this.element = document.createElement("button");
    this.element.appendChild(document.createTextNode("Receive Greeting"));
    this.element.greetingButton = this;
    this.element.onclick = this.greet;
}

GreetingButton.prototype.greet = function () {
    alert(this.greetingButton.greeting);
};

onload = function () {
    gb = new GreetingButton("Hello!");
    document.body.appendChild(gb.element);
    gb.greet();
};

This code works as intended, but the solution is inelegant. While it is unlikely that the name greetingButton will ever conflict with anything, you’re still essentially polluting someone else’s namespace.

Another problem with this approach is that it theoretically breaks encapsulation, since you are in fact setting up a backdoor to your logic. Anyone with access to the HTML document that your element is attached to could aquire a reference to your backdoored element, and, by extension, your private data. This will probably not present itself as a practical problem to anyone, but it necessarily remains a fundamental inelegancy.

Binding a variable to the value of this and then closing over it is a superior approach:

function GreetingButton(greeting) {
    this.greeting = greeting;
    this.element = document.createElement("button");
    this.element.appendChild(document.createTextNode("Receive Greeting"));
    var greetingButton = this;    this.element.onclick = this.greet;    this.element.onclick = function () {
        greetingButton.greet();
    };
}

GreetingButton.prototype.greet = function () {
    alert(this.greeting);
};

onload = function () {
    gb = new GreetingButton("Hello!");
    document.body.appendChild(gb.element);
    gb.greet();
};

function makeCounter(start) {
    var current = start;
    return function () { return current++; };
}

						
								var greetingButton = this;

						this.onclick = function () {
    greetingButton.greet();    this.greet();
};

Refactoring this a bit, we get the following:

function GreetingButton(greeting) {
    this.greeting = greeting;
    this.element = document.createElement("button");
    this.element.appendChild(document.createTextNode("Receive Greeting"));
    this.element.onclick = function () {
        greetingButton.greet();
    };    this.element.onclick = createMethodReference(this, "greet");
}

GreetingButton.prototype.greet = function () {
    alert(this.greeting);
};

function createMethodReference(object, methodName) {
    return function () {
        object[methodName]();
    };
};

onload = function () {
    gb = new GreetingButton("Hello!");
    document.body.appendChild(gb.element);
    gb.greet();
};

And thus we arrive at the essential point of this article. We have just discovered a basic method for “welding” a function and an object, forming what we have been calling a method reference.

I call this form of event listening “object-oriented,” because instead of attaching callback functions, you attach callback methods. When doing object-oriented programming, an equivalent or similar facility is nearly essential.

I say “through partial application” because partial application—i.e., informally, calling a function with only a subset of its arguments and getting back the remainder—is actually what createMethodReference does, or at least something very close.

Letting external arguments pass through method references

When you click a button on a web page, the browser calls the event listener referred to by the element’s onclick property. It sends one argument to the event listener: the event object, which says things like the exact coordinates at which the click occured.

However, using the above definition of createMethodReference, an event listener method has no way of accessing the event object. So we would like the method reference to pass on the arguments it receives—the event object, in this case—to the method it references.

function GreetingButton(greeting) {
    this.greeting = greeting;
    this.element = document.createElement("button");
    this.element.appendChild(document.createTextNode("Receive Greeting"));
    this.element.onclick = createMethodReference(this, "greet");
}

GreetingButton.prototype.greet = function (event) {
    alert(this.greeting);
};

function createMethodReference(object, methodName) {
    return function () {
        object[methodName]();        object[methodName].apply(object, arguments);
    };
};

onload = function () {
    gb = new GreetingButton("Hello!");
    document.body.appendChild(gb.element);
    gb.greet();
};

func.apply(obj, args);

obj.___tmp___ = func;
obj.___tmp___(args[0], args[1], args[2], ...);

But wait. In making the GreetingButton::greet method accept an event argument, we have introduced a subtle inconsistency: Users are also expected to call this method, and they will not be passing any event objects. To clarify the code, we should add some indirection:

function GreetingButton(greeting) {
    this.greeting = greeting;
    this.element = document.createElement("button");
    this.element.appendChild(document.createTextNode("Receive Greeting"));
    this.element.onclick = createMethodReference(this, "greet");    this.element.onclick = createMethodReference(this, "buttonClicked");
}

GreetingButton.prototype.buttonClicked = function (event) {
    this.greet();
};

GreetingButton.prototype.greet = function (event) {
    alert(this.greeting);
};

function createMethodReference(object, methodName) {
    return function () {
        object[methodName].apply(object, arguments);
    };
};

onload = function () {
    gb = new GreetingButton("Hello!");
    document.body.appendChild(gb.element);
    gb.greet();
};

Taking special measures for event listeners

If you want to be compatible with Internet Explorer (as of 2005), you usually have to put this code at the top of every event listener:

event = event || window.event;

To avoid cluttering up your code with such compatibility cruft, you can pull this logic into the function that creates the event listener method references:

function createEventListenerMethodReference(object, methodName) {
    return function (event) {
        object[methodName].call(object, event || window.event);
    };
}

(Note that in this case we assume that the method is always interested in exactly one argument, so we do not have to use the Function::apply method to pass arguments.)

Making method references not look like eval

You might want to be able to pass any function to createMethodReference instead of just a method name. That way, you can create method references to functions which aren’t really “methods” of the object in question (you might, for instance, be participating in an obfuscated JavaScript contest).

function createMethodReference(object, methodName) {
    if (!(method instanceof Function))
        method = object[method];

    return function () {
        method.apply(object, arguments);
    };
};

But perhaps more convincing is the fact that we no longer have to deal with strings whose content are more or less code:

				
						this.element.onclick = createMethodReference(this, "buttonClicked");
				
				
						this.element.onclick = createMethodReference(this, this.buttonClicked);
				
		

Giving method references a respectable look

The name createMethodReference is clearly long and awkward. We can improve on it by stealing a better name from Ruby, in which you can do the equivalent of createMethodReference by first obtaining an UnboundMethod (which is a roundabout way of saying “function”), and then binding it to some object. This is the terminology we’re looking for, so we’ll just rename our function to bind and make it a method of the Function class.

Function.prototype.bind = function (object) {
    var method = this;
    return function () {
        method.apply(object, arguments);
    };
}

function a() {
    var this = <object 1>;
    function b() {
        var this = <object 2>;
    }
}

Function.prototype.bind = function (object) {
    var this = <object 1>;
    var method = this;
    return function () {
        var this = <object 2>;
        method.apply(object, arguments);
    };
}

Function.prototype.bind = function (object) {
    var this = <object 1>;    var method = this;
    return function () {
        var this = <object 2>;        method.apply(object, arguments);        this.apply(object, arguments);
    };
}

Now we can use it like this:

				
						this.element.onclick = createMethodReference(this, this.buttonClicked);
				
				
						this.element.onclick = this.buttonClicked.bind(this);
				
		

Of course, you can do the same with the Internet Explorer-compatible event listener method reference creator. The obvious name would be bindAsEventListener, but let’s drop the “as”, as it’s only making the name more awkward.

Function.prototype.bindEventListener = function (object) {
    var method = this;
    return function (event) {
        method.call(object, event || window.event);
    };
}

More partial application (less-partial application)

We can already do partial application on the implicit this argument, but we can just as easily allow for more general partial application:

				
						// Some browsers don't like expressions such as foo.concat(arguments)
// or arguments.slice(1), due to a kind of reverse duck typing:
// an argument object looks like a duck and walks like a duck,
// but it isn't really a duck and it won't quack like one.
function entries(collection) {
    var result = [];  // This is our real duck.

    for (var i = 0; i < collection.length; i++)
        result.push(collection[i]);

    return result;
}
				

Function.prototype.bind = function (object) {
    var method = this;
    var preappliedArguments = entries(arguments).slice(1);
    return function () {
        method.apply(object, arguments);        var newArguments = entries(arguments);
        method.apply(object, oldArguments.concat(newArguments));
    };
}

With this definition of Function::bind, a call such as f.bind(o, 1, 2)(3, 4) will be rendered as f.call(o, 1, 2, 3, 4). The corresponding redefinition of Function::bindEventListener

Function.prototype.bindEventListener = function (object) {
    var method = this;
    var oldArguments = entries(arguments).slice(1);
    return function (event) {
        method.call(object, event || window.event);        method.apply(object, event || window.event, oldArguments);
    };
}

will cause f.bindEventListener(o, "moomin")("snufkin") to be rendered as f.call(o, event, "moomin", "snufkin"). This is handy whenever you want to attach an event listener in a certain “mode”. For example, you might have a grid of cells, each of which should react to click events.

function GridWidget(width, height) {

    // Create elements and populate cell array here.

    for (var x = 0; x < width; x++)
        for (var y = 0; y < height; y++)
            cells[x][y].element.onclick =
                this.cellClicked.bindEventListener(this);
}

GridWidget.prototype.cellClicked = function (event) {
    alert("I have no idea which cell you just clicked.");
};

As the message says, it is not obvious how to find out which one of the width × height different cells generated the click event, because all cells trigger the same event listener. It would clearly be ridiculous to attempt to manually define a separate event listener function for each cell, especially since the number of cells may very well be variable.

The solution, of course, is declaring the event listener to take two additional arguments giving the cell coordinates, and using partial application to plug these values in during object initialization.

function GridWidget(width, height) {

    // Create elements and populate cell array here.

    for (var x = 0; x < width; x++)
        for (var y = 0; y < height; y++)
            cells[x][y].element.onclick =
                this.cellClicked.bindEventListener(this, x, y);
}

GridWidget.prototype.cellClicked = function (event, x, y) {
    alert("I have no idea which cell you just clicked.");    alert("You clicked the cell at (" + x + ", " + y + ")!");
    this.cells[x][y].frobnicate();
};

Finally, it is useful to make the method references to pass on any values that the real methods return.

Function.prototype.bind = function (object) {
    var method = this;
    var oldArguments = entries(arguments).slice(1);
    return function () {
        var newArguments = entries(arguments);
        return method.apply(object, oldArguments.concat(newArguments));
    };
}

Function.prototype.bindEventListener = function (object) {
    var method = this;
    var oldArguments = entries(arguments).slice(1);
    return function (event) {
        return method.apply(object, event || window.event, oldArguments));
    };
}

For example, it is often necessary to return false from an event listener to signal that the default action should be suppressed.

Acknowledgements

I want to thank the following people for their help in writing and revising this article.

My dear friend Peter Wängelin provided the initial motivation for the article by asking some good questions that I felt deserved some good, written answers.

Sam Stephenson promoted the article by linking to it from his website and suggesting to people that they read it.

Mathieu van Loon corrected an error in the definitions of Function::bind and Function::bindEventListener, and suggested that method references should pass on the return values of the underlying methods.

Chih-Chao Lam pointed out the fact that argument objects cannot portably be used as arrays.

At least a few other people have linked to the article from various places on the web, and I want to thank them too.

Copying

Copyright © 2004, 2005, 2006 Daniel Brockman.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. Copies of the GNU Free Documentation License can be obtained at the following URL: http://www.gnu.org/licenses/