Saturday, April 28, 2012

Just a Promise

Warning: Code Examples are in CoffeeScript


I have been working on a javascript application over the past couple of months built with the Spine.js framework and things have gone really well. We are holding onto data for a current session and some of the less volatile data is only fetched once during that session and only when it's needed.


For example, we have "Discussions" and "Users" and we only fetch these models once during a session and in the case of a Discussion, we only fetch a full discussion one at a time. Also, while we batch fetch Users, we cannot guarantee when we render a Discussion along with Users and their avatars that all of the users are present at rendering time. This caused quite a bit of code that looks like this...

Yeah that sucks having code that looks like that littered all across the application and it can get even worse if you need to ensure that multiple pieces of data already exist...so tonight, I cleaned it up with a promise and am really happy with the results


Additional Reading/Resources:

Modular Javascript

Complex javascript apps and eco systems are the common norm these days and with javascript packaging and caching solutions that encourage all of your javascript to be served up in a single payload. Moving towards this paradigm brings up some interesting issues about how to keep your javascript organized, lean and fast.

A common pattern observed in javascript writing is to wrap your javascript code in a closure to control scope and namespace your "objects" to prevent variables being overwritten.

File structure looks like...

  • /javascript
    • house-app.js
    • house-initializer.js



With this approach, there are a couple of problems.

  1. Javascript file load order becomes important - if script block (a) depends on something from script block (b), script block (b) must be ensured to load before (a). In a complex app/site - you can end up with hundreds of javascript objects and managing one large file can become burdensome. Also, if you break these into multiple files, circular dependencies can become an issue.
  2. All javascript in the closure will always always run when the files are loaded (when #call is executed).
  3. Global scope is still relied heavily on to attach all "objects" to be used.

To solve these problems I recommend using a module pattern in developing your javascript such as CommonJS or AMD. If you have used node.js, then you have used the CommonJS implementation and if you have used "require.js", then you have used the AMD implementation of the module pattern.

I like the permise of the AMD implementation which provides a convention to asynchronously load required javascript files from a server as this prevents the need to have a large payload initial sent to a page to get up and running (faster page load time) but this advantage becomes moot after someone has visited the page once (with caching). Also, creating a javascript "app" that can easily run in an offline mode becomes more challenging because you have to deal with multiple files in a cache manifest file, etc. However, require.js has a solution to this and provides a utility to create one javascript file but relies on node.js to work (potentially introduces an additional dependency into your development/deploy env) and introduces another step into your deploy if using another asset bundling solution (asset pipeline, jammit, etc).

The way I prefer to handle the module pattern implementation is based on the CommonJS spec and is based off a node.js package called "stitch". In using this solution, the only thing you have to worry about in load order is your initial library dependencies (stitch-header.js, jquery.js, backbone.js, etc) and then the rest of your javascript can be loaded in any order. This simplifies specifying your javascript includes for your packaging solution and ensures that javascript only gets executed when necessary.

Here is the example from above using the the CommonJS pattern.

File structure now looks like

  • /javascript
    • stitch-header.js
    • /app
      • house-app.js
      • /models
        • house.js
        • window.js
        • door.js
      • /controllers
        • house_controller

Then to use the above the house app in the particular page that needs the house app, put a small script block at the top of the page that reads, "var HouseApp = require('house_app'); window.app = new HouseApp;"