My journey through the JavaScript pattern jungle

After you’ve been writing JavaScript for a while and get past the ‘just making things work’ stage, you start to look for ways to organise your code. This is where patterns come in.

There are a number of common JavaScript patterns, and a great place to learn about them is the book Learning JavaScript Design Patterns by Addy Osmani. There are also ES6 modules which are worth looking into, but this post isn’t about them.

Why not just use a framework?

These days it’s common to use a framework such as Backbone, Angular or Ember to structure your apps, but this hasn’t always been the case, and even today these can sometimes be overkill.

Namespaces

The first pattern I ever came across was this simple namespace pattern:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
var app = app || {};

app.config = {
  this.apiKey = 'ahdkl3sjdl20',
  this.url = 'http://google.com'
};

app.methodName = function (arg) {
  // Your code here
};

app.init = function () {
  this.methodName(this.apiKey);
};

app.init();

Initially I really liked this way of structuring my code, but after a while I found appending everything to the app namespace cumbersome.

Prototypes

I then came across this prototype pattern, which was already in use on the project I was working on:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
var app = function () {
  this.apiKey = 'ahdkl3sjdl20',
  this.url = 'http://google.com'
};

App.prototype.methodName = function (arg) {
  // Your code here
};

App.prototype.init = function () {
  var app = this;
  app.methodName(app.apiKey);
};

var myApp = new App();
myApp.init();

There are similarities to the namespace pattern above, but this is pattern is more verbose. It also requires you to make a new instance of it when you want to use it.

The revealing module pattern

Finally, I discovered the revealing module pattern:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
var myModule = (function () {
  var config = {
    apiKey: 'ahdkl3sjdl20',
    url: 'http://google.com'
  };

  var methodName = function (arg) {
    // Your code here
  };

  var init = function () {
    methodName(config.apiKey);
  };

  return function () {
    init();
  };
})();

There’s also a really cool way to expose methods too:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var myModule = (function () {
  var setSomething = function (arg) {
    // Your code here
  };

  var getSomething = function (arg) {
    // Your code here
  };

  return {
    set: setSomething(),
    get: getSomething()
  };
})();

Which means you can use it like this:

1
2
myModule.get(arg);
myModule.set(arg);

I really like this pattern as it’s so simple and comes with the benefit of everything outside the return statement being private, but still easily accessible within the module. I still use this pattern when I’m not using a framework.

Conclusion

I’ve used all of the above patterns on live projects, and of them all I’d recommend the revealing module pattern. But remember the goal is to make your code maintainable. You should always do what works for you and your team.