In the past year that I’ve been working at Yahoo! I’ve found myself more in the role of UI Developer in web application development.
This involves developing the client-side display, the client behaviors, request and response handling with server-based actions which may interface with a series of back-end or 3rd party services. HTML and CSS are used for content mark-up and styling. JavaScript is used for manipulating the client data and display based on user interaction. AJAX is leveraged heavily to interact with services. A Java based action layer sits on the server and acts as the controller for request dispatching, and interfacing with various services.
Given JavaScript’s heavy usage in this structure, I’ve learned a lot about JS limitations and powers. For years I generally avoided doing any kind of development that relied heavily on JavaScript. It’s implementation across browsers was disparate, and errors were impossible to debug. Things have obviously improved drastically in the past few years.
An increased usage and reliance on JavaScript means it’s very important to write “enterprise-level” code in a language that doesn’t always assist you the way Java or Python do in this task. One of the things I’ve always disliked about JS is its confusing variable scoping.
This article will cover a series of concepts in advanced JS usage which can help developers avoid problems caused by poor scoping. These concepts include:
- Namespacing
- Self-Invoking functions
- Closures
First, let’s cover the concept of namespacing in JavaScript. Normally, you can define variables in JavaScript in two different methods:
myFirstVar = "some value";
var mySecondVar = "some other value";
In the case of myFirstVar, this is a global variable, no matter where you define this it will be available to all other JavaScript code in the page/screen where it occurs. Using this method to declare variables is extremely messy. With large applications you can easily eat up a lot of memory if you’re declaring global variables all over the place. Also, there’s a strong chance that during the execution of your code, you will encounter a collision where the same variable is getting used for different intended uses.
The second case: mySecondVar uses the “var” keyword to limit the scope to the current executing block of code, and all blocks of code within the current one. If mySecondVar was inside of a function or a conditional block, then it would be local to those blocks of code. In the case above, it’s essentially another global variable.
To avoid polluting the global scope, we’ll use an object structure with a semantic naming pattern to store all code that we need available on a global scope, but we’ll run much less risk of code collision and we’ll have a smaller memory footprint.
Let’s pretend we’re writing code for dgmlive.com. We’ll create a global JS object called DGM:
var DGM = {};
We can add functionality as children to this object. We could for instance create a series of objects that correspond to data entities that we use in dgmlive.com, and those objects would contain data and behavior specific to those entities. Examples include:
- DGM.Artist
- DGM.Recording
- DGM.util.DownloadConfirm
- DGM.widget.MediaPlayer
Now, we’re still going to have situations where we’ll want to declare variables that don’t naturally fit into a namespaced object structure. But we don’t want those variables to have a global scope. This is where self-invoking functions come in.
Normally in JavaScript, you define a function at some point in your script, and later invoke it. With a self-invoking function, it’s executed when the definition is parsed by the browser / client. Variables declared inside of a self-invoking function using the “var” keyword only have a scope local to that self-invoking function. Here’s what a self-invoking function looks like:
(function() {
// All your JS code goes in here
})();
A functional example:
(function() {
var myThirdVar = "Try to get at this outside this function";
})();
alert(myThirdVar); // undefined
Let’s take these concepts further and incorporate some object oriented programming principles to our JavaScript code that aren’t explicitly provided for with basic JavaScript.
Let’s build a basic version of the proposed DGM.Artist object. Here’s the code:
var DGM = {}; // only global property, the root of our namespace
(function () { // Self-invoking function
/**
* Creates a new artist object
*
* @param Object an initial configuration for this artist
* @constructor
*/
DGM.Artist = function(
/* Obj */ oConfig
) {
// Define private members
var _name = oConfig.name;
var _givenName = "";
var _surName = "";
// Private logic method
// A not-so-good way of getting first and last name from a single name
var _splitName = function(name) {
var names = name.split(" ");
_givenName = names[0];
_surName = names[1];
};
return { // publicly accessible API
getName : function() {
return _name;
},
setName : function(newName) {
_splitName(newName);
_name = newName;
},
getGivenName : function() {
return _givenName;
},
getSurName : function() {
return _surName;
}
};
};
var robertFrippConfig = {
name : "Robert Fripp"
};
var newArtist = new DGM.Artist(robertFrippConfig);
alert(newArtist.getName());
alert(name);
alert(givenName);
newArtist.setName("Bobby Willcox");
alert(newArtist.getName());
alert(newArtist.name);
})();
Ok, there’s a lot there. Let’s walk through it a little at a time:
var DGM = {};
That’s the start of our namespace object. We’ll add children to it and avoid polluting the global namespace.
We then start a self-invoking function:
(function () {
It’s not really necessary to wrap the declaration of DGM.Artist in a self-invoking function, since this is just going to have the same scope as DGM, but it’s a nice touch. We do need the self-invoking function to contain the instantiation of DGM.Artist.
We declare DGM.Artist as a function, but we’re going to use it as an object constructor. It returns an object with a specific sub-set of functions that we want to make publicly accessible.
DGM.Artist = function(
/* Obj */ oConfig
) {
...
return { ... };
We create an instance of DGM.Artist using the new statement:
var newArtist = new DGM.Artist(robertFrippConfig);
Now let’s look closer at DGM.Artist. JavaScript doesn’t support different traditional OO member accessibility (i.e. public, protected, private). But we can use the “var” keyword and JS scoping to our advantage in this instance.
Variables declared with “var” inside of DGM.Artist constructor method are local to that method, and not accessible to JS outside of the method. However, the variables themselves persist inside each instance of that object. So, we can use traditional accessor methods (getters/setters) to manipulate those variables from outside. This behavior is called a closure.
This gives the programmer some power over how an object’s properties are manipulated during run-time. However, this shouldn’t be construed as any type of security measure to protect sensitive data.
So, getting back to the example, we set up a series of private variables which will contain data for each instance of DGM.Artist that we create:
// Define private members
var _name = oConfig.name;
var _givenName = "";
var _surName = "";
I’ve used the convention of putting an underscore in front of the member names. This does nothing other than visually indicate to the programmer that these are intended as private variables.
In the return block of the constructor method, I build an object which has a series of methods which can be used to manipulate these private variables after the instance is created:
return { // publicly accessible API
getName : function() {
return _name;
},
setName : function(newName) {
_splitName(newName);
_name = newName;
},
getGivenName : function() {
return _givenName;
},
getSurName : function() {
return _surName;
}
};
Take a look for a moment at the setName() method. This is used in the instance to change the name of the artist if necessary. Inside of setName() we call a private method _splitNames() defined in DGM.Artist constructor, which takes our name string and splits it into a given and a surname.
===
I hope this gives you some sense of how to avoid scoping problems in your JavaScript development, and also gives you some sense of how to use closures and object-oriented JavaScript to unleash some of the power that JavaScript has available.
