How YUI’s event listeners changed the way I write JavaScript

I really like Prototype.js. Its inclusion in Ruby on Rails got me writing JavaScript again. We at Schematic don’t recommend Prototype for client projects however, and I’m glad because the library or framework you use can greatly change the style in which you write code. And sometimes that can make you a better programmer.

Working with YUI helped trigger an epiphany for me this past week. Credit for laying the foundation for this moment goes to the sample chapter on Inheritance of Douglas Crawford’s new book, JavaScript: The Good Parts. I did not understand the practical usage for the techniques in the chapter at first because I learned Object Oriented design in classical OO languages like Actionscript 2, PHP5, and Ruby (which Prototype imitates as best as possible).

I’ve tried to maintain this style in JavaScript, especially in large projects like Silverlight 1.0 RIAs. I usually structured classes like this:

  1. var MyClass = function() {
  2.     // MyClass constructor
  3. }
  4. MyClass.prototype ={
  5.     method : function() {
  6.         // do stuff with the "this" object
  7.     }
  8. }
  9.  
  10. var myInstance = new MyClass();

I eventually extracted the new Class.create function from Prototype.js 1.6.0, because it gives you an elegant syntax for inheritance, mixins, and access to overridden methods without much overhead. It basically does the same as the above with some extra magic for creating the inheritance chain.

There’s nothing inherently wrong with this approach, and I think that anyone who tells you otherwise is a bit of a zealot. But it’s reliance on the this object creates problems, especially with event listeners. YUI made this very apparent:

  1. var GUIElement = function() {
  2.     var button = document.getElementById('button');
  3.     YAHOO.util.Event.addListener(button, 'click', this.onButtonClick);
  4. }
  5. GUIElement.prototype = {
  6.     onButtonClick : function(event) {
  7.         // this === button
  8.     }
  9. }
  10.  
  11. var element = new GUIElement();

The scope of the event handler is the button, which I believe follows the standard. However, I usually want this to refer to the instance of the class so I can access other methods and properties. The bind method in Prototype makes this easy by creating an anonymous function that executes the function in the specified scope:

  1. button.observe('click', this.onButtonClick.bind(this));

There are a few problems with this approach.

  1. bind uses Function.apply which adds overhead. It’s usually negligible but with JavaScript optimization is always a top priority.
  2. We’re not using Prototype! In this case, the client is a large e-commerce site and we’re only coding a small section of it. Prototype doesn’t necessarily place nice with other libraries since it defines a lot of global variables and augments the prototypes of build-in objects (like adding bind to Function).

You can specify the scope of the event handler with YUI, but it has the same effects as the first point above.

  1. // a "truthy" last argument makes the second-to-last argument the function scope
  2. YAHOO.util.Event.addListener(button, 'click', this.onButtonClick, this, true);

This felt very awkward to me, like I was doing something I wasn’t supposed to do. It’s perfectly valid but the awkwardness got a few gears turning in my head. I don’t think I can adequately explain my train of thought without turning this into an unreadable ramble, but here is how I’ve started writing components (using the module pattern):

  1. var GUIElement = function() {
  2.  
  3.     // define constants, like shortcuts to the YUI library
  4.     var Event = YAHOO.util.Event;
  5.  
  6.     // this "constructor" creates an object and passes it to functions
  7.     // instead of calling methods on the object itself
  8.     function create() {
  9.         var object = {}; // the instance
  10.         object.button = document.getElementById('button');
  11.         addEvents(object); // pass it to the function
  12.         return object;
  13.     }
  14.  
  15.     // we'll call the object "that" so it kind of looks like "this"
  16.     function addEvents(that) {
  17.         // pass "that" to the event handler, but don't change scope
  18.         Event.addListener(that.button, 'click', onButtonClick, that);
  19.     }
  20.  
  21.     function onButtonClick(event, that) {
  22.         // do stuff with that
  23.         // as a bonus, "this" still refers to the button
  24.     }
  25.  
  26.     return {
  27.         create: create // make create a public function
  28.     }
  29. }();
  30.  
  31. // the module pattern means no more "new" keyword
  32. var element = GUIElement.create();

And all of a sudden, Crockford’s techniques make sense! My paradigm shift is really just two ideas:

  • Encapsulate code into factories, not classes.
  • Functions act upon objects instead of being methods of the object that act upon itself (addEvents(that) instead of this.addEvents()).

I’ve yet to fully explore the ramifications of these techniques, but I wanted to try writing this down to see if it still makes sense. I won’t throw Class.create out of my toolbox just yet, but if I can understand an elegant way to do inheritance–or more likely, composition–I do think this will be the way to go 90% of the time. More on this topic to come.

Addendum: Curiously, Luke W posted an article while I wrote this about the exact component I was refactoring when this epiphany hit me.

June 1st, 2008 | JavaScript

« Blog goals Alex Russell at Google I/O »

2 Responses to “How YUI’s event listeners changed the way I write JavaScript”

  1. [...] Moore + Douglas Crockford = Epiphany: Lenny Burdette writes on his Rule52 blog about "How YUI’s event listeners changed the way I write JavaScript", bringing together insights from the sample chapter of Douglas Crockford’s JavaScript: [...]

    In the Wild for June 20 » Yahoo! User Interface Blog — June 20th, 2008 at 5:04 pm

  2. This pattern actually opens up more problems for you than if you were to use the prototypal method with partial function application that .bind() or YUI’s scope correction offers.

    The reason is because prototypal inheritance is incredibly memory efficient, whereas the Module pattern is not.
    Here’s why:
    When you create an object with new, for every object that you create, only one copy of the methods on that prototype is stored in memory.

    Your current implentation seems to be more of a factory, and on the face of it, it’s not super memory intensive. But there are going to be some major issues as soon as you start adding some public methods on the object that is returned from .create().

    Because your .create factory is returning a new object every time, but this object won’t be taking advantage of the prototypal inheritance, and so you will have multiple copies of the object floating around in memory.
    This would be much less efficient than the scope correction of either Prototype or YUI.

    I believe Class.create takes advantage of the prototype, and there are others that do as well.

    Just some thoughts :)

    Nate Cavanaugh — March 4th, 2009 at 3:03 pm

Leave a Reply