Tech Ravings

With plugins, widgets, and what-not’s every JavaScript author is vying for space on a web page, whether their own or someone elses. How then to keep the funciton literal names from colliding with other authors, or even previously written code? Writing JavaScript strictly with global functions really places you in a situation that someone may use the same name and make your function useless, and ultimately your entire program.

This is where namespacing your JavaScript reduces the risk of anyone colliding with your code. Quite simply namespacing in JavaScript is just as simple creating an object and attaching the functions to that object, the JavaScript Prototype scope, gotta love it. Yes, you are building a JavaScript object that sets all the methods apart from anything else someone would create. So this object can, and should, contain any needed functions that it needs to operate.

The actual naming convention of the object is really up you. I personally like to namespace of the object intent, Browser. (Browser detection object), TR. (functions relating to the general javascript of Tech Raving). The real intent is to use a name that someone else may not use. Take Browser for instance, what are the chances that someone else could use that for an object or function name? Probably pretty good. BrowserSJK as a name doesn’t really look good but now what are the chances that someone will use that!

To actually create a namespace object is relativly simple:

var TR = {
    method1 : function() {
        //Do stuff here
    },
    method2 : function() {
        //Do stuff here
    }
}

So now you can use TR.method1().

That’s good for a start but what about variables you would normally need. Easy enough to set up and use and gain access to:

var TR = {
    attribute1 : “hello”,
    attribute2 : “world”,

    setAttribute1 : function(temp) {
        this.attribute1 = temp;
        this.method1();
    },
    method1 : function() {
        //Do stuff here
    },
    method2 : function() {
        //Do stuff here
    }
}

TR.setAttribute1(”test”);

The difference in namespacing this way as opposed to just writing the variables and functions is the attachment to the TR object and the use of the this keyword to make the object reference itself in the executable scope. Here there be dragons when global scoping varibals and functions because of naming collisions, although it’s easy enough to access them if no collision occurs. Namespacing protects the variables and methods by wrapping them in an object, yet some care is needed by accessing them through the Namespace name, and using the “this” keyword for access outside of the method, yet referencing within the object namespace. Sounds complicated I know, it’s a prototype thing, but until you attach events to dynamically created html elements it’s really straight forward.

So what’s a developer to do if they have existing code that has either conflicted or just needs a little love and refactoring? That’s simple as well just create an object and then prepend all the methods and varibles with the Namespace.

old code:

var myVar1 = “hello”;
var myVar2 = “world”;

function method1() {
    //do Somtehing;
}

new code:

var myObj = new Object();

myObj.myVar1 = “hello”;
myObj.myVar2 = “world”;

myObj.method1 = function(temp) {
    this.myVar1 = temp;
}

myObj.method1(”test”);

Now the new code is protected from generalization of naming. Unless you have hundreds of lines of code the refactor should go quickly. If you have hundreds of lines of the old code I would highly suggest breaking into related objects using the same namespace approach.

JavaScript used to be authors writing code for their own sites in order to help acheive some dynamic capabilities. Maybe specialized libraries, such as menu’s or link generators where “given” out, but really only one was used on a publishers site. Now a days with the many widgets given out it’s quite common for publishers to have many third party JavaScripts and not from the same author. Namespacing is a way to protect your code as an author from the other authors.

As web 2.0 grows in popularity, it’s important for us developers to ensure that our code is tested and works even in the event of failure on another party.