Mah Controller!?

I humorously call Backbone a MVCn, which is shorthand for Model-View-Collection. There is no traditional controller as other robust JS MVCs state they have. The Collection being, a collection of Backbone Models (super relational-pimped objects, naturally)

It is difficult to grasp the convention to begin with, but once you get your mind around it, it is relatively simple.

My intention is not to explain every ounce of Backbones universal definition and spirituality, many other good people have done that

]]> Backbone.js is becoming the most go to tool for web applications due to its lightweight flexibility. There has been a lot of debate around JavaScript MVC libraries and which is better. Personally I have have not explored many alternatives in depth myself, which I will soon rectify. But on the table, I am having too much fun with Backbone.

Mah Controller!?

I humorously call Backbone a MVCn, which is shorthand for Model-View-Collection. There is no traditional controller as other robust JS MVCs state they have. The Collection being, a collection of Backbone Models (super relational-pimped objects, naturally)

It is difficult to grasp the convention to begin with, but once you get your mind around it, it is relatively simple.

My intention is not to explain every ounce of Backbones universal definition and spirituality, many other good people have done that

Setting up

In order to have a go at coding with Backbone, we need to bring in some libs.

<!-- In footer of markup -->
<script src="jquery.min.js"></script>
<script src="underscore-min.js"></script>
<script src="backbone-min.js"></script>

<!-- Your file -->
<script src="app.js"></script>

We all know what jQuery is, it is a requirement for these examples, but not a requirement for using Backbone. Feel free to use whatever lib of your preference. Zepto naturally falls on top of jQuery, use this if required.

The Underscore library is by the creators of Backbone and is a Backbone dependancy, so please make sure it is present. Consider it being Batman's utility belt, only for JavaScript.

As our Backbone code will be wrapped in a self-executing function, your files will need to be at the bottom of your markup, or the app.js at least.

// Inside app.js

// Self executing wrapper
(function ($) {

    // Our code goes here

})(jQuery);

There are more robust ways for setting up our code, but for simplicity, we shall use this.

Models

Models are the heart of any JavaScript application, containing the interactive data as well as a large part of the logic surrounding it: conversions, validations, computed properties, and access control.

Models are the key ingredient to the cake, this is where we contain and manipulate all of our data.

var Item = Backbone.Model;
// We now have a new Model type defined in Item

var bacon = new Item({ title: 'Bacon' });
// We have created a new Item Model, with the title attribute of 'Bacon'

The Backbone model has the traditional setters and getters.

bacon.get('title');
// => Bacon

bacon.set({ price: 2.99 });
// Damn expensive Bacon

bacon.get('price');
// => 2.99

Hell, we can even set defaults for Model attributes by extending the object with extend(). This extends onto the Models prototype, the same formula for Collections and for Views.

var Item = Backbone.Model.extend({
  defaults: {
    price: 0.99
  }
});

// Default price for Item Model now 0.99
// If we do not set or define a price, it will result to this default,

var cabbage = new Item({ title: 'Cabbage' });

cabbage.get('price');
// => 0.99

Collections

As our bowels digest the Bacon and Cabbage, lets put their Models into a Collection. As I stated earlier, a Collection is a literal collection of Models that are relevant to one another. I created a Model in the example above called Item , now I want to make a collection to put all these Items together. It would be only fitting to name our Collection Items,

var Items = Backbone.Collection.extend({
  model: Item
});

We have created a new Collection called Items, and we have set its relational Model to Item, meaning we will only be putting Item Models in the Collection.

Assuming we have our two Item Models defined,

var bacon = new Item({ title: 'Bacon', price: 2.99 });
var cabbage = new Item({ title: 'Cabbage' });

Let us add them to Items,

// Define a new Collection of Items as itemColleciton
var itemCollection = new Items();

itemCollection.add( bacon );
itemCollection.add( cabbage );

itemCollection.length
// => 2

// bacon and cabbage are now in our Collection

Now that we have a Collection sailing about looking for Models, this can make the above processes a little easier. For instance, we can initialize a Collection and pass soon-to-be Models as arguments, like so,

// Assuming we have the Item Model and Items Collection defined

// Make an array of items instead of defining them individually as Models
var list = [
    { title: 'Bacon', price: 2.99 },
    { title: 'Cabbage' }
 ]

var itemCollection = new Items( list );

itemCollection.length
// => 2

Nice, we made two new Item Models and added them to Items at the same time. Instead of defining them individually, passing them through the Items constructor kills two birds with one array.

Now we should have a basic understanding of Collections and how they work with Models.

Views

Views are self-explanatory, the visual side of the app, the UI, the data rendered.

The general idea is to organise your interface into logical views, backed by models, each of which can be updated independently when the model changes, without having to redraw the page.

We render our Models through a View, as our Model changes, so does our View.

var ItemView = Backbone.View.extend({

  // Our Views main container, which is a <ul> in the markup
  el: '#list',

  // Once this View is called, initialize is called
  initialize: function() {

    // We call this Views render function
    this.render();
  },

  render: function() {

    // We append this Models details to the Views container
    this.$el.append('<li>'+this.model.get('title')+
                    ' at '+this.model.get('price')+
                    '</li>');
  }

});

// Define some Models
var bacon = new Item({ title: 'Bacon', price: 2.99 });
var cabbage = new Item({ title: 'Cabbage' });

// Make some new Views and pass in the Models
new ItemView({ model: bacon });
new ItemView({ model: cabbage });

On successfully creating these two Views and passing in our Models bacon and cabbage, we should end up with something like this,

<ul id="list">
    <li>Bacon at 2.99</li>
    <li>Cabbage at 0.99</li>
</ul>

This seems like a lot of unnecessary effort to do something so simple that can be done with jQuery in a few lines. Correct, but, if you did things that way, your application has no formal structure. Updating and scaling would eventually become a nightmare if you are coding a verbose application in this style. Whereas with Backbone, we have our data and our visual, separated.

Now, the above example was to demonstrate how a Backbone View works, whilst not being an ideal solution. The ItemView is a View for a single Model. Bacon has its own View, as does Cabbage.

Ideally in apps, we would want to create a main View, to hold the above Views.

In my next post we are going to create an application that lists several items that we would normally shop for. We would then select some of those items which we need to get at the shop, and they would appear in the shopping list. Whenever we have got said item, we would tick it as collected.

What we will be going through that we have not touched yet is the following,

1. Underscore Templates
2. Fetching Model data from an extra source
3. Working with Multiple Views
4. Attaching events to our Views

The Backbone documentation is very limited, but there are plenty of awesome resources and tutorials out there.

Any questions or complaints, you should hit me up on twitter.