I recall reading a post recently which describes factory methods as a best practice. I can’t tell you how thrilled this made me as I’ve been advocating this for years, even to the extreme view that the author used as an example: new Form().

In my most recent talk at AJAXWorld 2009, I briefly discussed the Factory Pattern as it applies to JavaScript. In my talk, I took a jump away from simple best practices and gave a real-world problem/solution approach to factories in JavaScript.

The problem: JavaScript will allow you to invoke constructor functions as normal functions.
The simplest possible solution: Use a factory method to instantiate everything.

My personal recommendation is to only use constructors internally and to never expose constructors directly.

What the hell? Why are constructors so bad?

Constructors in JavaScript are bad because of one thing, and it’s the same thing that is at the heart of almost all of JavaScript’s problems: implied global scope.

Consider the following code:

// Define our constructor function
var Person = function (name, location) {
    this.name = name;
    this.location = location;
};

// Create one instance of Person
var mike = new Person('Mike G.', 'NYC');

// Create another instance of Person
var alex = Person('Alex H.', 'NYC');

Did you spot my mistake? I omitted the new keyword while creating the second Person instance. If you run this code in any web browser, you’ll notice that the browser will redirect you immediately upon running it.

This is a big problem.

When you invoke any function with the new keyword, it treats it as a constructor and executes within the context of the newly created instance. When you invoke any function without the new keyword, it treats it as a normal function and executes within the context in which the function was defined (typically window).

With that knowledge, go back and re-read the code and tell me why the browser redirects now…

Factories save the day

The easiest way to fix this problem is to use a factory. Here’s my proposed solution:

var Person = function (name, location) {
    return Person.factory(name, location);
};

Person.factory = function (name, location) {
    return new Person(name, factory);
};

One of JavaScript’s brilliant features is that Constructors can have return values. In this example, my constructor is returning the result of the Person.factory call.

Now it doesn’t matter how you invoke this constructor. You can use new or you can omit it. This is defensive code and it’s JavaScript done right.

As a small experiment, I decided to write a quick system that allows for synchronous execution of functions. In other words, a queue of functions which executes in order and only allows one component to execute at a time. My hopes are that by grouping the initialization routines into segments, the page will become more stable as the effort will be more distributed.

At first the solution sounds simple: just create an array of functions you wish to run, loop over the array and execute each function along the way.

Of course, it just doesn’t work like that. Function 0 may be complex and take much longer to execute than function 1. In this case, the order of function definition matters very little when compared to the time the function takes to execute.

If you’re stumped, I’ve posted the solution and a demonstration to the lovemikeg code repository. The breakdown works like this:

1. Like the first proposed solution, an array is used to store functions in the queue.
2. A next() method is defined which executes the next available function in the queue (if any).
3. Whenever a function is added to the queue it’s wrapped in a function which when executed defines another function passed to window.setTimeout. This inner function executes the original function and then immediately calls the next() method

It’s basic I know: There’s no prioritization… or scope overriding… or configurable parameters. This is however, a great example of the power of anonymous functions and closure in JavaScript. I’m not confident that this will translate over to other languages well, but the pattern certainly will.

Whether this turns out to be a good solution for distributing initialization effort has yet to be determined. As I learn more, I’ll update this post.

Update May 27, 2009: Looks like I’m not the only one thinking about this topic: http://cavaliere.org/async

You can find the talk’s abstract below. I’m still working on the slides so if there is anything you would like me to touch on, I’m open to suggestions.

From the Sessions page:

JavaScript has taken a lot of heat over the last few years for various reasons, one of which being it’s lack of proper object orientation. On the contrary, JavaScript is fully object-oriented, supports many types inheritance and also supports member visibility. This talk will explore the JavaScript programming language and will demonstrate several practical design patterns you can use in your JavaScript/Ajax application today.

On a somewhat related note, I really need to update my speaking bio and head shots. Any photographers in the audience?

Update: Here are the slides for those who missed out.

It’s widely known that the vast majority of JavaScript books that exist are bad. Unfortunately, I have another one to add to the list: Learning Dojo by Peter Svensson.

I fought with myself over whether or not it is a good idea to post this review. I’m afraid that this review may come across as an attack on the author, the publisher, or the reviewers of the book. Instead of looking at all of the errors in the book one-by-one, I am going to try to write an exhortatory post so I can better communicate what I would expect in any JavaScript book in this class.

To be fair, I don’t think that the blame for the book’s poor quality should be entirely on the author. From what I can gather simply from reading it, I would say this book was rushed and not properly reviewed for quality or accuracy. Also, I’m a purest when it comes to the web; so when I see [what I perceive to be] an outright dismissal of best practices, I start to get a little judgmental. Sorry, I can’t help it.

So, after over a month, I have finished reading the book cover-to-cover. I’ll admit that I part of the reason why it took me so long to get through the book was because I  lost interest about halfway through. Chapter 6, Layouts (linked below) is long, tedious and goes against nearly everything I stand for when it comes to building web pages. I simply had to keep putting the book down. Before I get ahead of myself, let me start off start off at the beginning and work our way down.

Source code should always be carefully formatted

Whenever someone asks me to critique a web site they have built, one of the first things I do is view the HTML source. If the developer has taken the time to make sure that the code indented properly and consistently spaced, I see that as someone who really cares about the quality of their project. I see it as a sign of a craftsman at work.

In the real world, this is a “nice to have” as it doesn’t really matter much — just as long as the page functions correctly, I don’t have much to complain about. In the world of tech books, however, properly formatted source code is a requirement. Remember, people learn from the source. Chances are, people will copy that down character-by-character and think that it’s the right way to do it.

Listen, JavaScript source code can be complex enough by itself. It’s an author’s responsibility to make sure that it’s as clear as possible so that good habit patterns are established from the jump. In nearly every source code listing in the book, I found something inconsistent, oddly spaced, full of errors, or simply impossible to read. This to me is completely unacceptable and was one of the first things I noticed while reading this book.

Even JavaScript books should encourage web standards

Almost every HTML document in the book was invalid. This was mainly due to the fact that Dojo itself encourages the use of custom attributes. Some may argue that there’s nothing wrong with this practice, especially when making use of a custom DOCTYPE. What’s worse is that the author made no effort to provide any alternative techniques let alone even discuss the dangers of deliberately writing invalid code. This may have been excusable ten years ago, but not in this day and age.

At the very least, I believe the author should have demonstrated an alternative technique for defining custom attributes — for example, using a combination of dojo.addOnLoad and setAttribute, or even better: not use custom attributes at all and use each respective dijit’s constructor.

eval is Evil

There is only one circumstance where the eval function should be used: parsing an Ajax response; and that’s only allowed after the response has been properly sanitized via a regular expression.

This is a concept which is well known and documented in every programming language with an eval function. Nothing further needs to be said about this.

JavaScript is deep; spend extra time on complex topics

Because I’m also working on a post where I explain closures in JavaScript, I was very pleased to see that the author had taken the time out to explain them in this book. Unfortunately, the explanation of closures in Chapter 2 left me more confused than when I had started — and I’m quite familiar with the topic.

Admittedly, the problem of JavaScript closures is two-fold: closures are incredibly abstract and secondly, almost nobody knows JavaScript’s full capabilities as a functional programming language. Source code helps to illuminate the complex topics, but a practical example should be carefully chosen. Two examples are given by the author, however one is broken and the other is completely misleading. This book is better off not even mentioning closures at all.

It also should be mentioned that your explanations should be technically correct. Let me quote the author’s explanation of how Ajax works:

In practices, what happens is that the browser opens a new iframe with zero height and width. Each iframe is capable of loading and posting data independently of each other, and so the accesses of the ‘invisible’ iframe will not affect the main page to be reloaded.

I’m not sure if the user was explaining how Dojo does Ajax or if he was trying to simplify the topic into familiar language, but the explanation is just wrong. This makes for a wonderful segue into the next, and equally important topic: proper terminology.

Never use improper terminology — ever

Programming is as much of a science as it is an art form, and as a result any sort of educational material should make use of proper terminology. In areas of introducing new concepts, it’s quite acceptable to use an analogy or reference another topic in order to build a frame of reference. For example, the author likens JavaScript objects to associative arrays. This is great because the name/value structure of objects in JavaScript are very similar to associative arrays; however, they are not the same thing. All throughout the book, the author uses the term “associative array” when he really means “use an object-literal as an associative array.”

In other instances, the terms “parameter”, “property”, and “attribute” are used interchangeably when referring to HTML attributes. Switching up vocabulary is just as dangerous as using incorrect terminology. Why? Because it makes you sound like you don’t know what you’re talking about. This is really bad when the people you teach start parroting this back.

Concluding Thoughts

There you have it, five simple things to keep in mind while reading this book or while attempting to write your own. I’ll say it again, I don’t want to attack anyone involved in the publishing of this book. That said, I won’t apologize for my response. The above mentioned topics are basic and there is simply no excuse for them to have slipped through the cracks.

At the time of this writing, absolutely no errata has been published for this book. This only adds to the reasons why I simply cannot recommend this book anyone, regardless skill level.

Believe it or not, I’m actually looking forward to this book as Dojo is one of the few libraries that I haven’t spent a great deal of time with. I’m certainly a fan of component libraries like Dojo, YUI, Prototype (YUI being my favorite) so at least the territory is familiar. I do remember there being a few things about the library that were immediate turn-offs to me, but seeing a few best practices mentioned in the book (that’s the secret to my heart, by the way) and also after the Dojo + Zend partnership announcement of last year, I think giving the library a second try is in order.

Chapter Summary

1. Introduction to Dojo
2. Useful JavaScript and Dojo Tricks
3. Basic Dijit Knowledge
4. Ajax Communication
5. Forms
6. Layout (PDF)
7. Data, Trees, and Grids
8. Real-World Dojo

The book itself seems to offer a pretty good introduction to the library (and JavaScript too). Check out the table of contents and see for yourself.

The Lazy Function Definition pattern was discovered and named by Peter Michaux.

Motivation

Generally there are two main reasons for wanting to defer defining functions until a later time (although with any pattern, many other applications exist):

1. Resources required for a function to be fully defined are not available until the page fully loads or until a user-driven event (for example, determining page scroll).
2. The resources created by defining the function are particularly taxing and may not even be needed (for example attaching event handlers).

Implementation

The Lazy Function Definition solves these problems by defining resources upon the first invocation of the function and then redefining itself so that they are not recreated during subsequent calls. All resources are stored via closure so they remain available to the inner function (which becomes the new definition for the outer function).

var getResource = function () {
    var resource, counter;

    resource = 'foo';
    counter = 0;

    getResource = function () {
        return resource + ' has been accessed ' + (++counter) + ' times';
    };

    return getResource();
};

In the code above, a getResource function is defined. When the function is called the first time, resource and counter are created to store important information which is needed in future calls to getResource.

The function which immediately follows redefines the original getResource function, but because resource resource and counter are defined in the same scope as the inner function, they remain available.

Finally, the new getResource is executed and it’s value is returned. Now any future calls to getResource will use the inner function.

Conclusion

The Lazy Function Definition pattern allows for deferred function definition as well as insuring that resources that only need to be created once, are created once.

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition

This pattern was originally discovered and named by Douglas Crockford.

Motivation

By default, there is no natural data hiding functionality in the JavaScript language. As developers push the limits by continually creating more complex applications, the need for private object members becomes increasingly apparent.

Implementation

Modules are simply a standard self-invoking function who’s return value is an object of properties and methods which serve as a public API. In the example below, foo.bar is not being set to the value of the anonymous function but rather the object that is returned by the anonymous function.

foo.bar = (function () {
    var baz = function () {};
    var bif = function () {};

    return {
        'thud' : function () {},
        'grunt' : function () {}
    };
})();

foo.bar now has an object as its value which contains two methods: thud and grunt. baz and bif are not available publicly, however thud and grunt still have direct access to them through closure.

Understanding Closure

Closure is a byproduct of functional programming whereby inner functions have access to local variables defined within an outer function, even after the outer function has returned.

There are several important facts to understand:

1. Functions can contain other functions, just like any other variable. These are inner functions.
2. Anything not returned by the outer function will not be directly available, however it still exists and is available to any inner functions that shared the same scope.

Conclusion

With the ability to implement public and private members in an API, developers now have the ability to create robust APIs in JavaScript. This allows developers to create powerful applications while exposing only what is necessary to make it function.

The Module also introduces the concept of closure. This is an extremely powerful concept of JavaScript which is a result of its functional nature. Future patterns in this series will make heavy use of closure in order to better understand its power and to show the various ways it can be applied.

Posts in this Series

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition

Load time configuration is also known as load time branching.

Motivation

The primary motivation behind load time configuration is to optimize conditional operations such as generating XMLHttpRequest instances or adding event listeners. Since both operations vary amongst clients, specific conditions must be checked before proceeding. The load time configuration pattern runs once at load time and sets the resulting value so that it doesn’t need to be checked again.

Implementation

The most common technique for implementing load time configuration is by way of a Self-invoking function which returns the correctly configured value.

The example below demonstrates how load time configuration can be used to normalize getting an XMLHttpRequest object.

var getXHR = (function () {
    if (window.XMLHttpRequest) {
        return function () {
            return new XMLHttpRequest;
        }
    }
    else if (window.ActiveXObject) {
        return function () {
            /* Msxml2 and Msxml3 checkes have been omitted
             * for simplicity's sake */
            return new ActiveXObject('Microsoft.XMLHTTP');
        }
    }
})();

First, a getXHR variable is declared and it’s value is being assigned by the self-invoking function that follows. Upon execution, a conditional is run which determines the correct method of obtaining an XMLHttpRequest object. When a match is found, a wrapper function is returned and stored as the value for getXHR variable.

Conclusion

The load time conditional pattern is used to configure a conditional value at load time. The result is a fully optimized value, specific to the the environment in which it is to be used.

Posts in this Series

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition

Self-invocation (also known as auto-invocation) is when a function executes immediately upon it’s definition. This is a core pattern and serves as the foundation for many other patterns of JavaScript development.

Motivation

The primary motivation behind self-invoking functions is to create scope. In JavaScript, only functions have scope. Any time variables are defined outside of a function, they are carelessly dumped into the global object.

Implementation

A self-invoking function is a standard function, just with a set of parentheses appended to the end.

function () {
    var foo = 'Hello';
    var bar = 'world';
    var baz = [foo, bar];
    alert(baz.join(', '));
}();

The above example defines an anonymous function. This creates a literal function, yet since no name is attributed to it, the value is never stored. The trailing parenthesis tell the function to execute, just as if you were calling a named function.

Upon execution, the above function creates three variables, formats them, and alerts them to the user. Once the function terminates, the variables are discarded and the global object remains unchanged.

Distinguishing from Actual Functions

Given the oddness of the pattern (and lack of widespread understanding), it is very possible for developers to misinterpret this pattern as an actual function. It it recommended that an extra set of parentheses wrap the function definition as well so to provide a visual clue to the developer that the function isn’t a normal function. The result would be as follows.

(function () {

    var foo = 'Hello';
    var bar = 'world';
    var baz = [foo, bar];
    alert(baz.join(', '));

})();

Passing Parameters

In the event where a self-invoking function requires parameters, they can be passed in the same manor that you would a regular function.

The following example applies an “negative” class on every input element who’s numeric value is below 0.

(function (elements) {

    for (var i = 0; i < elements.length; i++) {
        if ((elements[i].value * 1) < 0) {
            elements[i].className = 'negative';
        }
    };

})(document.getElementsByTagName('input'));

Executing in Another Scope

Even though the function is executing within its own local scope, the this keyword will still refer to the global object.

The following example uses the Function.call() method to execute a self-invoking function within the scope of the first table element on the page.

(function (elements) {

    for (var i = 5; i < this.rows.length; i++) {
        this.rows[i].className = 'hide';
    }

}).call(document.getElementsByTagName('table')[0]);

Conclusion

In an effort to protect the global object, all JavaScript applications should be written within a self-invoking function. This will create an application scope in which variables can be created without the fear of them colliding with other applications.

If a global variable is needed, developers must take the extra step by setting them directly within the window object. For example window.foo = ‘bar’;.

Self-invocation is a fundamental pattern of professional JavaScript development. Nearly every pattern in this weeks catalog uses it as a base to create scope, closure, or to configure cross-platform objects on-the-fly.

Stay tuned folks. This will be a good week.

Posts in this Series

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition

This was my first presentation at NYPHP. It was also the first time I ever went to a formal meeting where we didn’t just network and drink beer (although there was plenty of that following the presentation).

You can view or download the presentation at Slideshare. I also have the sample code which I used to demonstrate my concepts.

Enjoy.