Category Archives: backbone

Chaining Backbone Plugins with Require.js

You may have run into this situation.. You are building a backbone application, and you want to take advantage of any number of plugins.. let’s say for this example, extended models and caching.. oh, and you also want to override some of backbone’s prototypes, because you have some custom needs (my use case – adding pointer.js to the event object to handle click/touch events). Let’s also say you are using require.js, because if you aren’t using either require or something like browserify, you should be (please don’t argue which one is better, for my particular use case, browserify is not an option).

In any case, you have a bunch of plugins which extend Backbone, but you don’t want to have to attach them all to each of your modules. It would be oh-so-much easier to just be able to do define([‘backbone’]… since you want access to all of these, everywhere…

Require.js and the shim to the rescue:


require.config({
paths: {
        jquery: '../components/jquery/jquery-2.0.mobile',
        backboneBase: '../components/backbone/backbone',
        underscore: '../components/underscore/underscore',
        backbone: 'plugins/backbone.overrides',
        DeepModel: 'plugins/backbone.deep-model',
        Cache: 'plugins/backbone-fetch-cache',
},
shim:{
        underscore: { exports: '_' },
        backboneBase: {
            deps: ['jquery', 'underscore'],
            exports: 'Backbone'
        },
        backbone:{
          deps:['backboneBase'],
          exports:'Backbone'
        },
        Cache:{
            deps:['backbone'],
            exports: 'Backbone'
        },
        DeepModel: {
            deps: ['Cache', 'underscore', 'plugins/underscore.mixin.deepExtend']
        },
}
});

That’s the code.. so what exactly are we doing here?

First, we’re setting aliases to all the backbone related script files that we need. Second, we’re using shim to load each in the order that we need them to properly set up extension availability. For example, I have a file that overrides the default View.delegateEvents method to convert click events to pointer.js standardized pointer events (so it works for mouse or touch). I want to load this one as the main backbone export, so I call it backbone, and the original, unadulterated backbone is ‘backboneBase’.

Next, I want to add the fetch-cache and deepModel plugins. Since I’m already referencing define([‘DeepModel’… in my project, I want to make sure Cache is always available with DeepModel, so I load it as a dependency to DeepModel. It exports Backbone with fetchCache attached. If I changed my code to define([‘backbone… I would lose both of these extensions.

You can play around with how you want to name/load your extensions in order to provide the module setup that fits your project. I’m sure someone has a better way for me to do this, and I’d love to hear it!

Yeoman, Karma, jQuery, Require, Backbone, SASS, Mocha, Dust, i18n… oh my!

I’ve added a skeleton file directory / config to github in order to perhaps save you time in setting up an application using the tools listed in the title.

https://github.com/mrforbes/yeoman-backbone-stack

The main reason I added it was because getting Testacular Karma working with require was not as straightforward as I had originally assumed it would be, owing to the fact that you need to tell Karma which files to include, but require wants to include them all asynchronously. The workaround is in the karma.conf.js file:

files = [
  MOCHA,
  MOCHA_ADAPTER,
  REQUIRE,
  REQUIRE_ADAPTER,
  'app/scripts/config.js',
  {pattern: 'test/lib/chai.js', included: false},
  {pattern: 'test/test.js', included: false},
  {pattern: 'app/nls/*', included: false},
  {pattern: 'app/nls/**/*', included: false},
  {pattern: 'app/templates/*', included: false},
  {pattern: 'app/scripts/*.js', included: false},
  {pattern: 'app/scripts/libs/*.js', included: false},
  {pattern: 'app/scripts/plugins/*.js', included: false},
  {pattern: 'test/spec/*.js', included: false},
  'test/test-main.js'
];

 

The included:false command tells Karma the files will be there, but it doesn’t inject them into the head, which leaves require to do its thing.

The second spot to notice is test/test-main.js… This is where all of the actual test files need to be added, instead of in the karma.conf.js file. You still need to alert Karma to them ( {pattern: ‘test/spec/*.js’, included: false} ), but you don’t want them loaded that way.

Here’s test-main.js:

require({
  // !! Karma serves files from '/base'
  deps: ['app','main'],
  baseUrl: '/base/app/scripts'
}, [
/* test runners go in here */
'../../test/spec/example',
'../../test/spec/i18n',
'../../test/spec/router',
'../../test/spec/index'
], function() {
  window.__karma__.start();
});

 

Pretty self-explanatory. Karma will wait to start until all of the specs have been loaded.

So.. if you have the need, grab the repo. Keep in mind this is a skeleton not a finished app, so some of the structure decisions are likely not optimal, and definitely not final. Move stuff around to suit your style / needs.

 

UPDATE 3/11/2013: I’ve updated the git repository to the Yeoman 1.0 beta. The 1.0 version of yeoman has some major changes in it, so the new application framework reflects those changes.

I’ve also added the following:

  1. JsHint watching
  2. Karma through Grunt (watching through Grunt)
  3. Debug code removal (grunt-groundskeeper)
  4. Backbone form validation, model binding, and deep model libraries
  5. Dust templates were always there, but I never mentioned them in the original post

UPDATE 5/3/2013: Testacular has been renamed Karma (for which I am thankful). I changed my references to match.

Thinking Big… Architecting a large application with jQuery / Backbone / Require, an Overview

A Little Background

Recently at work we’ve been in heavy development mode on a new thick-client application architecture.  If you aren’t familiar with the concept, thick-client essentially means putting most of the work onto the client’s processor, and removing it from the server.  The benefits of this are many, not the least of which is a much faster site response time for your users, and a much lighter load for your server.

To accomplish this basically means using javascript and a lot of AJAX, as well as implementing the application such that that a) search engines can still index your site and b) the user can both bookmark and use the back button wherever they are in your app.

In order to facilitate this heavy use of ajax and management of state, a number of MVC(ish) patterned javascript libraries have been created, and more appear seemingly every week.  After a little bit of research, we settled on Backbone due to its barebones nature, low overhead, lesser learning curve, and the size of the community.  It always helps to be able to reach out when you get stuck.

In combination with jQuery (we are already using it heavily), and Require.js (a dynamic resource loader which has also been in use for quite a while), we had the perfect trinity of tools to get the job done.

Basic App Structure

There are a lot of things to consider when architecting a large application.  For HMS, this is compounded by the fact that a) we have a lot of users with a lot of different site configurations, b) we have different variations on the main backend application, c) there is a lot of legacy code and newer front-end logic that needs to maintain compatibility so that pieces can be added one at a time.   This is where Require and its support of AMD (asynchronous module definition) really shines.

All of our thick-client application code is managed through AMD, and there are two things about it that are very awesome:

  1. It allows seamless integration on a module-by-module basis with the current application code
  2. Even portions of modules can be broken out and used before their parent module is complete – for example, we already have the autocomplete module live, even though the search module is still in development. When the time comes, it will be trivial to move it back into its proper place.

The general application structure goes like this:

  1. Event Aggregator
    Outlined here, we have a single global object, and its job is to manage communication between modules.
  2. Outer Router
    We have two routers.  This helps keep the application router a lot simpler, and keeps module related logic inside the module. The outer router manages routes for the entire application, and determines which modules to load.
  3. User Module
    Right now, this is the only module that sits everywhere in the application. As such, it is loaded by the outer router.
  4. Modules
    Each module contains its own router as well as templates and views. The router loads the views, the views load the templates (we’re using Hogan).  When we compile with require, each module (including templates) becomes a single file (the module router).
  5. Models
    The models are the glue between the client and the server,  and they sit in their own folder because multiple modules may use the same models.
  6. Form Mediator
    This is actually one of the modules, but its worth describing here.  We use a special Backbone view to handle every form, enhancing functionality as we go.  This view simplifies forms immensely, managing the model, validation, and state with ease.  Its special power is to allow multiple modules to combine into a single form definition – most usefully for search / advanced search.
  7. UI Modules
    Most DOM manipulation (outside of insertions/removals)  and all UI effects are offloaded into separate UI modules.  The reasons for this are a) it separates presentation concerns and b) it allows for a much easier time should we decide to switch from jQuery for future manipulation (one can dream of full standards support across browsers)
  8. Backbone.Store (localStorage)
    Of course we’re using this for our app.  Currently it persists forms, helps maintain the user session client-side, and caches model data.

Obviously, there are many ways to architect a thick-client application.  Our approach intends to prevent module dependency (outside of UI Modules), separate DOM manipulation from data logic, keep communication centralized in an event aggregator, load quickly (through smart module loading and use of localStorage, among other things), and preserve the global namespace through the use of AMD.  There are a lot of details I’ve left out (for instance reuse for mobile), but I do hope to dive a little deeper in future posts.

 

 

Backbone Resources – Become a Badass Chiropractor.

In the process of trying to get the dev team here at Homes Media Solutions up to speed on Backbone, I’ve been collecting links to a diverse range of articles, resources, etc. on the subject. Following is a curated list of what I believe are the best resources for learning Backbone and being badass at it (in no specific order).

  1. Backbone Fundamentals
    Open source e-book, started, curated, edited by Addi Osmani.  Still being written, but in time sure to become the defacto free reference to Backbone development.  There are lots of other good resources at the bottom of this page.
  2. Event Aggregator using Backbone
    An elegant solution to a common application problem.
  3. Data-binding with Backbone
    Derek  Bailey (see #2) is awesome.
  4. Understanding MVC And MVP (For JavaScript And Backbone Developers)
    Addi Osmani’s post on the history of the aforementioned patterns, and how they relate to the Backbone world.
  5. Recipes With Backbone ($24)
    Okay, this one isn’t free, but it goes through some useful Backbone patterns for dealing with common application architecture concerns.
  6. Peepcode Backbone Screencasts ($12)
    If you are a total Backbone beginner, these screencasts are worth every one of those twelve dollars.  Peepcode has a few Backbone related screencasts on their site, so don’t just settle for the basics (which is linked here)

And here is a bonus link because it’s worth looking at and following the links that branch off of it:

Javascript Patterns Collection  by Shi Chuan – a list of patterns and anti-patterns to make your javascript awesome.

Introducing Backbone.Store … JSON storage for Backbone.

Right now, you can’t do much better for quickly developing javascript applications and modules than the triumvirate of  Backbone, jQuery, and Require.  Each of these libraries fit together so well (IMO), and have increased my personal productivity immensely – improving quality, performance, readability, and consistency.

There was already a great library for Backbone to utilize HTML5 localStorage functionality; however, there were a few drawbacks to the library that caused me to look in another direction, and ultimately led me to creating Backbone.store.

My two greatest needs were:

  1. The ability to utilize the storage mechanism as a cache.
  2. A greater range of compatibility outside of localStorage support.

To meet these needs, I turned to Lawnchair, a JSON storage library with a wide range of adapters for different storage types, mixed in a little bit of the aforementioned backbone.localstorage plugin, and came out with the beginnings of a (hopefully) useful storage middleware.

While the overall project is in very early stages, its not too soon to look at, play with, and provide feedback on.

Download / clone from Github.

Features:

  1. Can be used with or without a backend server
  2. Configurable cache time to live
  3. Configure when to use server vs cached model – great for list  vs. detail of a record
  4. Does not require localStorage support, though a Lawnchair adapter may be needed to get the support you want.

Planned enhancements:

  1. Batch model upload to server (online/offline or time delayed)
  2. Parameter based caching (for caching paging / search results / etc)
  3. Remove Require (AMD) dependency
  4. ??? (accepting ideas)

Also included in the project is a basic ‘Todo’ style application including a CodeIgniter (php) based RESTful web server and structure, and a Backbone/Require/jQuery front-end consisting of a list/detail view with complete CRUD control and proper routing using both direct (bookmarkable) URL access and pushState routing.

Again, this project is nowhere near complete, so I’m sure there are some bugs… Still on the todo list is to add test cases using Sinon and Jasmine, and there is a known issue with the list -> detail -> list navigation.