JavaScript: The Namespacing Pattern

This post is the Part 2 of the JavaScript Design Pattern series. Check out the series’ Introduction and Index for proper acknowledgements and credits.

The following links will take you to the previous or the next chapter:

< JavaScript: The Object Literal PatternJavaScript: The Module Pattern >

The purpose of Namespacing our code is to avoid Name Collision: we might inadvertently use the same identifier as one of our dependencies (Libraries/Framework depended upon by our Code.

“Developer getting a ticket for polluting the Global Scope”. Oil on Canvas, circa 1915 (by Isidor Kaufmann).

Even though we might be using the Object Literal Design Pattern, we are still putting new objects directly on the Global Scope and, as the code gets bigger and as we rely on more 3rd party libraries, the chances of having variables overwritten gets higher.


Prefix Namespacing: The Instinctive Way

One of the first things that I would try to do is to use long, descriptive and probably unique identifiers, mentioned as early as 2008 in JavaScript by Peter Michaux:

This might work well on a really small project… but in that case it might not be needed at all.

And if you’re working with organized modules and functions that can be properly ordered, you might try adding some sense to the prefix:

As our project grows and we rely on more and more external dependencies, these techniques may not be enough. And it gets harder and harder to control what has or hasn’t been already used.


Prefix Namespacing: Object Notation

JavaScript is designed on a simple object-based paradigm. An object is a collection of properties, and a property is an association between a name (or key) and a value.
— Mozilla Developers Network

As I’ve mentioned in the Object Literal Design Pattern post, transforming our variables into properties and our functions into methods is a nice way to reduce the footprint of our code.

We can go one step further and transforms our objects into properties of an encompassing object, structuring our code and protecting the Global Scope:

Remember Java? Oracle.bought.Sun.and.Java

As Addy Osmani points out in the “Learning JavaScript Design Patterns” book: Object Literals “are truly beneficial if you wish to create easily readable structures that can be expanded to support deep nesting. (…) also take into account tests for the existence of a variable by the same name, so the chances of collision occurring are significantly reduced.”

Variable Collision seen in the wild. (by Alexas_Fotos)

So how do we test for the existence of a variable with the same name?

There are many ways to accomplish this, but the two most common ways are:

  • Short-circuit Assignment: var objectA = objectA || {};
  • Conditional assignment: if (!objectA) { objectA = {} };

They both accomplish the same thing: if objectA doesn’t exist, declare it as an empty object, allowing properties and methods to be set.

This is the same example used by Ben Fhala on his Packt Publishing JavaScript Course (adapted to our context):

If the variable already exists… keep it! If not, create it.

So basically this approach prevents the overwriting of any previously existing variables. If the variable already existed, the || operand will short-circuit and the variable will remain the same.

The one thing I like about this approach is that it really keeps things nicely structured and organized. It’s neat!

You can check the Index of this series on the JavaScript Design Patterns introductory post.

Want to stay up to date? I’m also on GitHub and Twitter (how unexpected!).