Backbone.js Patterns and Best Practices

We will look into some basic concepts of Backbone.js and Underscore.js before moving to the plugin development section. Backbone.js is a client-side MV* framework that provides a set of tools and building blocks required to structure a JavaScript application. Important tools that Backbone.js offers are as follows:

Apart from these, there are other tools such as Backbone.History, which manages the browser history and the back/forward buttons in accordance with the routers. Also, we have Backbone.Sync, which is a single method that provides a nice abstraction to the network access through Backbone models and collections.

Underscore.js (http://underscorejs.org/) is a powerful utility library that provides a lot of functional programming support for your JavaScript code. In general, JavaScript comes up with a very low number of utility methods on its own, and most of the time we need to either develop our own functions or depend on another library for these methods. Underscore comes up with a bagful of highly efficient utility methods, which makes it an excellent tool for your JavaScript projects. The functions it provides can be grouped into the following sections:

These include functions for iterations, sorting, filtering, conversions, templating, comparisons, scope binding, and many more. The main benefits of using this small library are as follows:

Backbone.js has a hard dependency on Underscore.js, and you are bound to use it if you are developing your applications with Backbone.js. However, even when you are not using Backbone, we encourage you to use Underscore.js for your JavaScript projects. It adds no overhead, integrates easily, and makes your code more robust even when you are not aware of all the underlying engineering principles employed by this library.

There is another library named Lo-dash (http://lodash.com), which provides an Underscore built to perform drop-in replacement of the Underscore.js library. It is said to have a slightly better performance than Underscore.js. You can try either of them to achieve the same result.

Backbone is quite a small library in comparison with other libraries. Any complex application can be structured and developed with Backbone, but the framework itself doesn't come with prebuilt widgets or reusable UI components. In this section, we will talk about some Backbone and JavaScript techniques that will help you build a reusable interface library.

For simple and small applications, code reusability doesn't always seem much of a necessity. But as you proceed to create an application with multiple views, models, and collections, you find that a certain portion of your code gets repeated several times. Creating reusable extensions and plugins in such cases improves the performance of the application by enhancing modularity and reducing the code size. Let's create a simple Backbone view to understand how we can create an extension, shown in the following code snippet:

var User = Backbone.Model.extend({
  defaults: {
    name: 'John Doe'
  }
});

var UserItemView = Backbone.View.extend({
  template: '<span><%= name %></span>',
  render: function () {
    var tpl = _.template(this.template),
      html = tpl(this.model.toJSON());

    this.$el.html(html);
    return this;
  }
});

// Create a view instance passing a new model instance
var userItem = new UserItemView({
  model: new User
});

$(document.body).append(userItem.render().el);

The view named UserItemView is a simple Backbone view where we want to display our model data inside a template and append this view element to the DOM. This is a fundamental functionality of Backbone where the primary requirement is to display a model's data as a view. If we have another similar view with a model, and this has the same functionality, the render() function will also be identical. That said, won't it be beneficial if we move the common code to a base class and extend that class to inherit the functionality? The answer is yes. Let's see how we can do that in the example in the following section.

// Parent view which has the render function
var BaseView = Backbone.View.extend({
  render: function () {
    var tpl = _.template(this.template),
      data = (this.model) ? this.model.toJSON() : {},
      html = tpl(data);

    this.$el.html(html);
    return this;
  }
});

// A simpler view class
var UserItemView = BaseView.extend({
  template: '<span><%= name %></span>'
});

var UserItemView = BaseView.extend({
  tagName: 'div',
  template: '<span><%= name %></span>',
  render: function () {
    // Call the parent view's render function
    BaseView.prototype.render.apply(this, arguments);

    // Add your code here
    this.anotherFn();
    return this;
  },

  anotherFn: function () {}
});

var BaseView = Backbone.View.extend({
  render: function () {
    var tpl = _.template(this.template),
      data = (this.model) ? this.model.toJSON() : {},
      html = tpl(data);

    this.$el.html(html);
    return this;
  },

  close: function () {
    // Extra stuff goes here

    // Remove the view
    this.remove();
  }
});
// This is not production-ready code, but it clearly gives you the concept of using custom widgets to reduce boilerplate in your code. It will not always be necessary to extend a Backbone class to create a plugin.

// Pagination constructor function
var Pagination = function (collection, noOfItemsInPage) {
  if (!collection) {
    throw "No collection is passed";
  }
  this.currentPage = 1;
  this.noOfItemsInPage = noOfItemsInPage || 10;
  this.collection = collection;
}

// Use Underscore's extend method to add properties to your plugin
_.extend(Pagination.prototype, {
  nextPage: function () {},
  prevPage: function () {}
});

var User = Backbone.Model.extend({
  defaults: {
    name: 'John Doe'
  }
});

var Users = Backbone.Collection.extend({
  model: User
});

var paging1 = new Pagination(10, new Users());
var paging2 = new Pagination(20, new Users());

In the previous section, we saw that inheriting properties from a parent class prototype provides a great deal of reusability. In some cases, we may want to re-use similar methods in multiple views, models, or collections. This can be achieved by creating a parent class that they can extend; however, it is not always a good practice as it creates some unnecessary layers and meaningless subtypes.

For example, assume that you want the view element of UserItemView, which already extends BaseView, to be draggable. So you include a DraggableView class that extends the BaseView class, and your UserItemView extends DraggableView. Now there is a sudden change in the requirement and you are asked to make the view named UserItemView a sortable view as well. Will you introduce another new class, SortableView, and put it somewhere in the chain? If yes, then this multitiered inheritance will surely create a logic that is absolutely unmanageable and frustrating. Look at the following figure that describes the situation in a better way:

What is a mixin?

Fortunately, there is a feasible alternative in JavaScript, which is called m ixin. In general computer science, a mixin is a class that provides a set of functions relating to a particular type. These mixin classes are not instantiated, but their functions are just copied to the main class to achieve a similar inheriting behavior without entering into the inheritance chain. Look at the following figure to understand the concept:

We have a ListItemView class that extends the BaseView class and represents an individual item of a list. Now we want these items to be draggable. How we can achieve this? How about adding a few methods in the ListItemView class that will take care of the dragging functionality? This approach will work, but what if we have few more components that need to be draggable too? Then we have to make a reusable object with these methods and use that object in all the required classes. This is what the mixin concept is—a collection of methods that will be copied to the class that wants this functionality.

// A simple object with some methods
var DraggableMixin = {
  startDrag: function () {
    // It will have the context of the main class 
    console.log('Context = ', this);
  },
  onDrag: function () {}
}

// UserItemView already extends BaseView
var UserItemView = BaseView.extend({
  tagName: 'div',
  template: '<%= name %>'
});

// We just copy the Mixin's properties into the View
_.extend(UserItemView.prototype, DraggableMixin, {
  otherFn: function () {}
});

var itemView = new UserItemView();

// Call the mixin's method
itemView.startDrag();

UserItemView.prototype.startDrag = DraggableMixin.startDrag;

// Functional mixin
var DraggableMixin = function (config) {
  this.startDrag = function () {};
  this.onDrag = function () {};

  return this;
}

// DraggableMixin method is called passing the config object 
DraggableMixin.call(UserItemView.prototype, {
  foo: 'bar'
});
// SortableMixin.call(UserItemView.prototype);

new UserItemView().startDrag();

// Functional mixin with cache
var DraggableMixin = (function () {
  var startDrag = function () {};
  var onDrag = function () {};

  return function (config) {
    this.startDrag = startDrag;
    this.onDrag = onDrag;

    return this;
  };
})(); 

// Simple function
function foo(){
  console.log(arguments);
}


// We want this bar object to be available in the foo() function
var bar = {
  name: 'Saswata Guha'
};

// Calling foo() without passing anything. Using curry, the 
// function will have the bar object in its scope
foo();  

// Definition of curry
Function.prototype.curry = function () {
  var slice = Array.prototype.slice,
    args = slice.apply(arguments),
    that = this;
  return function () {
    return that.apply(null, args.concat(slice.apply(arguments)));
  };
};

// Functional mixin with cache
var DraggableMixin = (function () {
  var startDrag = function (options) {
    console.log('Options = ', options);
  };
  var onDrag = function () {};

  return function (config) {
    this.startDrag = startDrag.curry(config);
    this.onDrag = onDrag;

    return this;
  };
})();

DraggableMixin.call(UserItemView.prototype, {
  foo: 'bar'
});

If you ever checked the annotated source code (http://backbonejs.org/docs/backbone.html) of Backbone, you might have found that the library footprint is very small (the production file is only 6.4 KB at v1.1.0). Its sole purpose is to improve the structure and maintainability of your code with the least complexity. So, once you start using Backbone, you will find that in every step of the development, you need to write custom widgets and plugins. In this chapter, we learned the basics of Backbone.js and the utility of using Underscore.js with Backbone.js. We also saw how developing reusable components and custom pugins can reduce boilerplate from our code. In the end, we understood the concept of JavaScript plugins and discussed different approaches for defining mixins. We are going to use all these concepts several times in the following chapters.

In the next chapter, we will discuss different problems associated with Backbone views and possible solutions to them. We will also see how custom-view plugins or mixins can solve most of the problems.