Flattening the Backbone.js Learning Curve

I just spent some time getting into Backbone.js finally.  The learning curve was a little steeper than I expected, mostly because I think I expected Backbone.js to be something that it is not.

From the docs:

Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions,views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.

Well not exactly. Backbone.js doesn’t give structure. It gives you the tools to create structure.  A minor nitpick maybe, but it makes a difference when you are trying to understand how something works and you can’t find the parts you expect to be there.

The docs are well written, the examples numerous, and there are also several blog posts which try to help you get started. Oh, and there is the totally awesome annotated source.

Still there were a few things I wish I had understood before I dove into a tutorial.  This post is my attempt to try to help boost someone up the learning curve a bit. The idea is not to get into many details or app design philosophy.  Not being an MVC ideologue myself, I care little about how things ought to be.  I am just trying to get to the essence of what the parts actually are. I’m also skipping some things on purpose, as I said the docs are well written.

Models/Collections

Key Idea 1: Wrapper for a hash of properties and that can trigger events when the properties change

Key Idea 2: Includes code to load and store from a Rest API

Models and Collections are the data management objects in Backbone.js.  The Model is really a wrapper for state for an object. Each model object has a field “.attributes” which is a map of the data managed by this model.  Since you change the data using .set methods of the model, this allows the model to trigger events when the data changes:

A Collection is a collection/list of models. Duh.

Both Collections and Models are able to fetch themselves from a server if you have a nice API.  Just set .url for the object foo and call foo.fetch().  An ajax call will be made to the server and the data will be loaded or added (you can chose with an option). You can also save a model to the server. And you can do lots more, including overriding virtually all of this.

Views

Key Idea: Wrapper for a DOM object which renders it based on events and other state

Views are what tie into the DOM. Each view attaches to a DOM object. You can set this to one in your document or the View will create a new one ( a <div> by default) when you create the View object.  It’s your job to make sure the element is in the page in the right place in the hierarchy. The View always keeps a reference to the DOM element in .el or .$el if you prefer the JQuery wrapped version.

A view generally has an associated model and listens for changes in that model,  re-rendering the DOM objects when a change occurs. The view subscribes to events on the model and calls the views render method to update the DOM objects based on the new data. Generally this is done via a client side template mapping the Model’s attributes into HTML.

Routes

Key Idea: Custom events or state which work with browser history

Routes allow you to define new URLs within a single page application that can trigger events in your app. You create a router object which includes a bunch of defined url routes which are pretty similar to the urls.py in django actually. The routes/urls have parameters which are passed to the callback function when that state is reached.

Calling router.navigate() will set a new state which allow the user to move around using forward and back in the browser. This is done via #tags which you give as names to the routes.

Don’t forget to call Backbone.history.start() before using Routes.