After more work with Backbone on projects at Sheepdog, we are starting to develop a solid foundation that will allow us to easily develop, test, and maintain our Backbone.js applications. Having these properties in our JS / CoffeeScript is very important, as we're striving toward better test coverage from server to client in order to best deliver the highest quality product to our clients.

The approach that I'm taking to solve our problem is a simple implementation of two common design patterns found in MVP applications. The Observer Pattern, and the Factory Pattern.

I, Observer Obtaining much of my MVP knowledge from one of our products written in GWT (gTrax) using the awesome GWT-Presenter and EventBus libraries, it's been ingrained into my being that all independant pieces of the application should communicate exclusively over an agreed-upon API. Rather than touting the benefits of modular code, I'll assume that since you're still reading this you understand. EventBus helps consolidate communication while developing in java and GWT, and I didn't have to look far to find a flexible solution already available. Backbone already mixes in the Backbone.Events class into all core pieces of the framework so it's the perfect candidate (shaving a yak, and all that). While I've seen this pattern implemented a few times, at Los Techies most notably, it has been missing a key piece of the puzzle. Either people are binding an instance of Backbone.Events directly to the window, and operate using that, or manually pass an instance of it to each view they create. I have two main problems with these methods which I'll outline in my review of the following code example. problem.coffee 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 class MyView extends Backbone . View tagName: "div" events: "click .close_button" : "closeView" "change input" : "formChanged" initialize: -> # ... some post-constructor stuff # bind on our eventBus object @options . eventBus . bind "globalEvent" , @respondToGlobal render: -> # ... $ -> eventBus = _ . extend {}, Backbone . Events # Create a view, pass the bus myView = new MyView eventBus: eventBus # Create a second view, and pass the event bus to it as well mySecondView = new MyView eventBus: eventBus My first problem with the above code is that it doesn't follow the IMO "Awesomeness" that is Backbone.js style. I am of the opinion that one of the best parts of Backbone is how they suggest you structure your View classes. To me it is immediately obvious that, in the above class declaration: The View will render in a <div></div> .

. It responds to a click event on the .close_button class.

class. It watches for changes on any form inputs, then calls formChanged . There is a key piece of information is being tucked away in MyView 's declaration. It registers its most important event globalEvent which gets exposed via the global eventBus. It should be a first class citizen along with events and tagName which clearly outlines how the View will behave. The second problem I have with the above code is that you're required in your implementation to create your own instance of Backbone.Events and pass it to each view you want to create, anywhere in the application. This isn't the worst thing, however, what happens when your views have 2 dependencies? 3? 4? ...

Enter F%#tories So many programmers cringe when they hear the word Factory. Factory, factory, factory, factory. Now that you've said it 5 times it just sounds silly and we can talk about them seriously and without cringing. This following ViewFactory solves the second problem that I had with our initial introduction to the Observer pattern above, and I'll address the first and most serious problem a little later. factory.coffee 1 2 3 4 5 6 7 8 9 10 11 12 13 class ViewFactory constructor: -> @eventBus = _ . extend {}, Backbone . Events @registry = factory: @ register: (key, value) -> @registry [ key ] = value create: (ViewClass, options) -> options = options or {} passedOptions = _ . extend options , @registry , eventBus: @eventBus klass = ViewClass klass.prototype.eventBus = @eventBus new klass ( passedOptions ) usage.coffee 1 2 3 4 5 6 7 8 9 10 $ -> factory = new Factory myView = factory . create MyView # or $ -> factory = new Factory factory . register "foo" , "bar" ... In 10 lines of coffeescript, I've shown how you can have a simple factory that is useful in a few key ways that are advantageous for structuring a large Backbone.js application. It will automatically bind the eventBus (Observer) object to any class we create. It has a registry that will bolt onto Backbone's @options for any View built using the factory for when your views become more complex and require additional dependencies.