Backbone.js: Hacker's Guide Part 3

2012-08-02 00:00:00 +0100 by Alex R. Young

Last week we continued looking at Backbone.js's internals, covering collections, and some interesting points about the chainable API design and its relationship to Underscore.js. Before continuing with this week's post, here are some interesting articles that are in a similar vein to this series:

I've already mentioned the first on DailyJS, but I thought I'd mention it again in case you're still feeling lost about what exactly MVC frameworks can do.

Meanwhile, I'm working on a tutorial series based on Backbone with a focus on combining it with a certain popular user interface component framework, and using a non-REST HTTP API. I'll release the app itself within the next few weeks.

Router and History

The Backbone.Router constructor function is like the other Backbone classes, based around Underscore's extend method. Routes are defined with the route method, and it will call _routeToRegExp if the route is a regular expression. This uses isRegExp, which is one of Underscore's handy type checking methods.

You can use Underscore's type checking methods in your own projects rather than reinventing them. For example, a lot of projects include a function to check if an argument is an array, but if you've already loaded Underscore then _.isArray can be used instead.

Most of what the router does is delegated to Backbone.History. These two classes work together -- once a set of routes has been defined and instantiated, then Backbone.history.start must be called. Backbone is probably known for supporting hash URLs at this point, but it also supports the HTML5 History API.

The History class is where Backbone has to do a lot of work to get good cross-browser support, and this is particularly apparent in the start method:

this.options          = _.extend({}, {root: '/'}, this.options, options);
this._wantsHashChange = this.options.hashChange !== false;
this._wantsPushState  = !!this.options.pushState;
this._hasPushState    = !!(this.options.pushState && this.history && this.history.pushState);
var fragment          = this.getFragment();
var docMode           = document.documentMode;
var oldIE             = (isExplorer.exec(navigator.userAgent.toLowerCase()) && (!docMode || docMode <= 7));

if (oldIE && this._wantsHashChange) {
  this.iframe = Backbone.$('<iframe src="javascript:0" tabindex="-1" />').hide().appendTo('body')[0].contentWindow;

To use the History API, pushState: true must be supplied as an option, and the browser must support it. Otherwise, hash URLs will be used, or even iframes. Regardless, the checkUrl method will be called by listening to popstate, onhashchange, or by polling with setInterval.

Like other Backbone methods, start also accepts a silent option. Passing silent: true prevents loadUrl from being called when start is run. This is one of those small touches that shows just how consistent Backbone is.

The Backbone.Router class adds routes by calling Backbone.history.route. The Router class wraps the callback supplied by the user, and the History class adds it to an array of handlers. When the URL changes in the browser, the handlers array is searched, and if a match is found then the callback will run. Due to the way the callback is wrapped by Router, it actually triggers an event.

The beauty of this design is these events can be bound to elsewhere, and the navigate method which changes the current URL is a lot easier to implement:

app.navigate('help/troubleshooting', { trigger: true, replace: true });

This calls the router's navigate method, which subsequently calls the one in History. URLs can either be replaced or added to the history array.


Backbone.View is a relatively simple class that helps manage view fragments and events. It takes steps to ensure it has a valid DOM element to work with by calling _ensureElement, and includes methods for delegating DOM-related functionality to jQuery-like framework calls in the form of $ and make.

The most interesting part of this class is delegateEvents, which loops over the events property and applies the delegateEventSplitter regular expression to the event property's keys. This is how Backbone turns things like 'click .button.edit': 'openEditDialog' into the usual jQuery syntax. This method is called by the constructor, and a lot of care is taken to correctly unbind events before adding or altering the view's main element. You'll see a few calls to undelegateEvents throughout the class to manage this.


I've written Backbone applications without using routers, so it's interesting to take a deeper look at it and appreciate just how much effort has gone into making it cross-browser.

Although a lot of people see the Backbone.View class as a simple wrapper, it does handle correctly binding and unbinding events, and ensuring there are valid elements to work with.