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.

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.

Posts in this Series

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module

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

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

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.

Part Three: Events

| View | Upload your own

Part Four: Writing JavaScript Applications

| View | Upload your own

Other Posts in this Series

• JavaScript From Scratch: Parts One and Two

Update: In my code example below, I make use of a self variable. This probably isn’t the best idea in hindsight since JavaScript reserves self as a secondary reference to window.

I’m always fascinated by the JavaScript language. What impressed me most, almost a year ago, was my discovery of Douglas Crockford’s module pattern. This was my first taste of what I consider to be the most intriguing thing in programming: closure. I didn’t understand the concept of closures when I first saw it, but after getting deeper and deeper into the language, it finally clicked. At that point I realized the potential of this type of language.

A few days ago, Peter posted his list of JavaScript warning words. To my surprise, “this” made the list.

Don’t get me wrong, I’m well aware of JavaScripts scoping issues, but it was still startling to see such a common element of my code sitting next to words like with, void, and eval.

He’s right though. If you’re not careful, “this” could quickly become problematic. For example, a constructor method declared without “new” would result in “this” being a reference to window and not the newly created object… oops.

This also becomes a problem when you use “this” in callbacks used for events. When methods are applied as event handlers, “this” generally refers to the element on which the event was applied — not the object that the function lives in when you write the code.

Peter advocates the use of closure as a means to reduce dependency on “this.” Today, I discovered an interesting pattern which does just that. Instead of relying on the ambiguous “this”, the following code creates a “self” variable in the module which is available in the inner functions as a replacement for “this”.

var mikeg = function () {
    /* Create an internal reference to self as a replacement for this */
    var self = {};

    /* Return out self and some methods which have access to itself */
    return self = {
        SomeConstructor : function () {
            console.log(window !== this);
            console.log(self === mikeg);
        },

        someCallback : function () {
            console.log(window !== this);
            console.log(self === mikeg);
        }
    };
}();

It seems so obvious now that my fingers have found their way toward this code, but then again, isn’t that always the case? Looking back, I’m sure I’ve seen this elseware, but much like my original discovery of the Module, it didn’t click until after a little while.

This whole series presents a basic set of knowledge that I think any front-end developer should know.

Part One: Getting Your Feet Wet

This talk talks about the four basic building blocks of programming: variables, conditionals, loops and functions.

| View | Upload your own

Part Two: Playing With Data

This talk details the data types available in JavaScript applications. Strings, Numbers, Booleans, Arrays, and Objects are discussed. Functions as values has been omitted until a later talk.

| View | Upload your own

If you want to see me speak, see if you can get your boss to pay for your fare. The lineup for the recent AJAXWorld East was pretty phenomenal (Doug Crockford gave the keynote… need I say more?) and I’m certain this event will be even better. If you can’t get your boss to flip the bill, submit a proposal. At the time of this writing the CFP is still open.

For those of you who are interested, my session abstract is as follows:

The Beauty of JavaScript

JavaScript is one of the most interesting and misunderstood programming languages in common use today. Most developers will go their entire careers without realizing its full potential. It’s not often that you get a language that supports the feature set that JavaScript does, while still being as widely deployed. This talk will spotlight some some patterns surrounding JavaScript’s most elegant features such as closures, lambdas, object and array literals, object prototypes, private members and dynamic scope resolution — all without boring you to tears.

You’d be hard pressed to find a JavaScript application that doesn’t manipulate the DOM nowadays. Usually there are a few elements that are manipulated often enough for them to be stored away in a property someplace for easy reference. If this sounds like any application you’ve written, you may like this.

Lets assume I have a registration form where users sign up for an account on a site:

MIKEG.widgetShop.registration = {
    'elements' : {
        'username'   : 'account-username',
        'password'   : 'account-password',
        'firstName'  : 'account-first-name',
        'lastName'   : 'account-last-name',
        'email'      : 'account-email',
        'messageBox' : 'system-messages'
    },

    'usernameExists' : function (sUserName) {
        // Code...
    },

    'validateData' : function () {
        // Code...
    },

    'renderMessage' : function (text, type) {
        // Code...
    }
};

The registration object stores an elements property which contains a set of property:value pairs which form the basis of this pattern. The property value contains the value of the ID attribute of the element we wish to reference.

When the DOM is in a usable state, you can safely load all of your element references into the elements property replacing the ID values with actual element references.

YAHOO.util.Event.onDOMReady(function () {
    var elements = MIKEG.widgetShop.registration.elements;

    for (i in elements) {
        elements[i] = YAHOO.util.Dom.get(elements[i]);
    }
});

And there you have it. Now anywhere inside the registration object you can simply address the element you want to target by this.elements.whatever. I’ve come to find that not only is this convenient, but it reads well and reduces code density substantially. Just look at how nice the implemented renderMessage method gets:

'renderMessage' : function (text, type) {
    this.messageBox.innerHTML = text;

    if (typeof type !== 'undefined') {
        YAHOO.util.Dom.addClass(this.messageBox, type);
    }
}

This weekend I was surprised to discover that there was no planet for JavaScript related blogs. So I made it. Inspired by one of Chris Shiflett’s recent posts about how he made one, I decided to give it a go and build one myself. All in all, it was a great experience and wasn’t all that difficult. I began Saturday afternoon and finished Sunday afternoon. Probably the hardest thing about the process was finding good JavaScript blogs.

Here’s a question for the community: Where are all the JavaScript bloggers?

At any rate, it was an incredibly fun project and anyone who finds themselves reading a lot of feeds in a specific category, should try to whip one up. Here’s some of the basics things to keep in mind:

• There are two main types of feeds floating around the internets today: RSS and Atom; both of which do the same thing but very differently. It would be worth the time if you took a moment to sit down and read up on them a bit. WikiPedia has examples of both RSS and Atom feeds that you can dissect and learn from.
• Content from other people’s blogs will interfere with your content. There is a good chance that you use the same ID attribute on something that someone else has and as a result your layout breaks. It’s also possible that they just have a poorly marked up site which will cause yours to fail validation. Either way, you need to clean up the bad content that will come your way. I suggest getting friendly with HTMLPurifier. It’s a gem.
• Consider how you are going to store the data. If you are just going to cache the data in a flat file, you don’t need to do much; but if you plan on any amount of scalability, you’ll probably use a database. There are a lot of characters in XHTML that will cause databases to flip out. Make sure you have a good escaping routine to take care of those potentially dangerous characters. If you are a MySQL and PHP user, use mysql_real_escape_string.
• People post regularly on blogs so you need to update your planet regularly. You could have a nice admin area with a big shiny “Update” button but manual updates suck. Simple websites like this should run themselves. I created a cron job to call a command-line PHP script that fetches the latest headlines and saves them to my database every six hours.
• Last but not least: Think about how you are going to prevent duplicate entries from being saved. I’m simply checking the posted date but I’m sure that some error will pop up. Another alternative would be to generate a md5 sum of the content and compare it to a sum of what’s stored in the database. That sounded like a lot of work and I quickly lost interest.

I’ll post the source code soon. I hacked it together procedurally and am currently integrating it into another little project I have going which you will soon hear about.

Check the site out. Give me some feedback. Blog about JavaScript.