Monday, November 21, 2011

How I use Backbone.js Views as modules

In my previous post I explained how I use views as a basic class structure. Here I will go a bit deeper into how I use them.

At the base there is the traditional Backbone.js view.  Used as one would normally use it, to set up the container, hook up the events, and structure your code.  This is a nice way of compartmentalizing functionality.  But let’s say that you have two views, or pieces of functionality, say a popup functionality and an ajax form functionality.  You  could initialize the two views separately and then hook them together using a controller ( more on that later ) but if you do this a lot, and this is the sort of thing one would do a lot if they are using popups, then this get’s terribly tedious. 

So I employ what I call a module.  It’s an extended view that has a views collection ( object ) a modules collection and a destroy function();  Then I inherit this module, and in it I instantiate the ajax form view, the the popup view put the form in the popup and render. I put both views in the modules view collection.  The destroy method loops through the modules and the views that belong to the module and calls destroy and remove on them respectively.  Now I can call new AjaxPopupModule() pass in an el ( a root element ) and a url and possibly other stuff and I’m all set.

Using Backbone.js views as a class structure

So what I’ve ended up doing is using Backbone.js Views basically as a class structure.  I used to use immediate functions or static objects or whatever you want to call them, basically

var x= (function(){

return {

}

}())

for everything.  And I always had an init function to set it up.  The limitation was that I could not inherit from those classes so I eneded up duplicating code a lot.

So, as I was saying, I’ve adopted backbone.js views as my class structure.  I can inherit these classes, they are constructor functions so I can put set up code in the function and they offer a few bonus features as well, such as if I have straight up events I can use the views event declaration infrastructure.  But overall what I like the most about it is that I can create base classes that have the functionality that I use a lot on them.  Now I know I could write my own class structure and implement all these features as well as a couple I’m about to mention that I don’t like, myself, but a) I’m kind of scared of constructer functions with prototypal inheritance and b) I believe ( hope ) that the structure will be familiar to people who use backbone.js ( such as my team ) and they will understand what is going on more easily.

The one thing I don’t like about using backbone.js views as my base class structure, is that it doesn’t implement any override functionality.  You can overwrite but not override and call base().  This would be great for such things as having a function on a base class called registerSubscriptions() that lays out the common subscription.  Then in my inhertied classes I could override it add page specific subscriptions then call base().

The way I get around that now ( and there are I guess a couple of similarly distateful ways ) is that I have my base registerSubscriptions() call registerAdditionalSubscriptions() as it’s last step.  in the base class I stub out the method so it won’t crash and in my sub classes I overwrite the method if necessary.