Table of Contents for

JavaScript Web Applications

Ensuring that there’s a clear separation between your application’s views, state, and data is crucial to keeping its architecture uncluttered and sustainable. With the MVC pattern, data management happens in models (the “M” of MVC). Models should be decoupled from views and controllers. Any logic associated with data manipulation and behavior should reside in models and be namespaced properly.

In JavaScript, you can namespace functions and variables by making them properties of an object. For example:

var User = {
  records: [ /* ... */ ]
};

The array of users is namespaced properly under User.records. Functions associated with users can also be namespaced under the User model. For example, we can have a fetchRemote() function for fetching user data from a server:

var User = {
  records: [],
  fetchRemote: function(){ /* ... */ }
};

Keeping all of a model’s properties under a namespace ensures that you don’t get any conflicts and that it’s MVC-compliant. It also prevents your code from spiraling down into a tangled mess of functions and callbacks.

You can take namespacing a step further and keep any functions specific to user instances on the actual user objects. Let’s say we had a destroy() function for user records; it refers to specific users, so it should be on User instances:

var user = new User;
user.destroy()

To achieve that, we need to make User a class, rather than a plain object:

var User = function(atts){
  this.attributes = atts || {};
};

User.prototype.destroy = function(){
  /* ... */
};

Any functions and variables that don’t relate to specific users can be properties directly on the User object:

User.fetchRemote = function(){
  /* ... */
};

For more information about namespacing, visit Peter Michaux’s blog, where he’s written an excellent article on the subject.

Object-relational mappers, or ORMs, are typically used in languages other than JavaScript. However, they’re a very useful technique for data management as well as a great way of using models in your JavaScript application. With an ORM, for example, you can tie up a model with a remote server—any changes to model instances will send background Ajax requests to the server. Or, you could tie up a model instance with an HTML element—any changes to the instance will be reflected in the view. I’ll elaborate on those examples later, but for now, let’s look at creating a custom ORM.

Essentially, an ORM is just an object layer wrapping some data. Typically, ORMs are used to abstract SQL databases, but in our case, the ORM will just be abstracting JavaScript data types. The advantage of this extra layer is that we can enhance the basic data with more functionality by adding our own custom functions and properties. This lets us add things like validation, observers, persistence, and server callbacks while still being able to reuse a lot of code.

if (typeof Object.create !== "function")
    Object.create = function(o) {
      function F() {}
      F.prototype = o;
      return new F();
    };

var Model = {
  inherited: function(){},
  created: function(){},

  prototype: {
    init: function(){}
  },

  create: function(){
    var object = Object.create(this);
    object.parent = this;
    object.prototype = object.fn = Object.create(this.prototype);

    object.created();
    this.inherited(object);
    return object;
  },

  init: function(){
    var instance = Object.create(this.prototype);
    instance.parent = this;
    instance.init.apply(instance, arguments);
    return instance;
  }
};

var Asset = Model.create();
var User  = Model.create();

var user = User.init();

// Add object properties
jQuery.extend(Model, {
  find: function(){}
});

// Add instance properties
jQuery.extend(Model.prototype, {
  init: function(atts) {
    if (atts) this.load(atts);
  },

  load: function(attributes){
    for(var name in attributes)
      this[name] = attributes[name];
  }
});

assertEqual( typeof Asset.find, "function" );

var Model = {
  /* ... snip ... */

  extend: function(o){
    var extended = o.extended;
    jQuery.extend(this, o);
    if (extended) extended(this);
  },

  include: function(o){
    var included = o.included;
    jQuery.extend(this.prototype, o);
    if (included) included(this);
  }
};

// Add object properties
Model.extend({
  find: function(){}
});

// Add instance properties
Model.include({
  init: function(atts) { /* ... */ },
  load: function(attributes){ /* ... */ }
});

var asset = Asset.init({name: "foo.png"});

// An object of saved assets
Model.records = {};

Model.include({
  newRecord: true,

  create: function(){
    this.newRecord = false;
    this.parent.records[this.id] = this;
  },

  destroy: function(){
    delete this.parent.records[this.id];
  }
});

Model.include({
  update: function(){
    this.parent.records[this.id] = this;
  }
});

// Save the object to the records hash, keeping a reference to it
Model.include({
  save: function(){
    this.newRecord ? this.create() : this.update();
  }
});

Model.extend({
  // Find by ID, or raise an exception
  find: function(id){
    var record = this.records[id];
    if ( !record ) throw new Error("Unknown record");
    return record;
  }
});

var asset  = Asset.init();
asset.name = "same, same";
asset.id   = 1
asset.save();

var asset2  = Asset.init();
asset2.name = "but different";
asset2.id   = 2;
asset2.save();

assertEqual( Asset.find(1).name, "same, same" );

asset2.destroy();

At the moment, every time we save a record we have to specify an ID manually. This sucks, but fortunately, it’s something we can automate. First, we need a way of generating IDs, which we can do with a Globally Unique Identifier (GUID) generator. Well, technically, JavaScript can’t generate official, bona fide 128-bit GUIDs for API reasons—it can only generate pseudorandom numbers. Generating truly random GUIDs is a notoriously difficult problem, and operating systems calculate them using the MAC address, mouse position, and BIOS checksums, or by measuring electrical noise or radioactive decay—and even lava lamps! However, JavaScript’s native Math.random(), although pseudorandom, will be enough for our needs.

Robert Kieffer has written an easy and succinct GUID generator that uses Math.random() to generate pseudorandom GUIDs. It’s so simple that we can put it inline:

Math.guid = function(){
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
    var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
    return v.toString(16);
  }).toUpperCase();
};

Now that we have a function to generate GUIDs, integrating that into our ORM is simple; all we need to change is the create() function:

Model.include({
  create: function(){
    if ( !this.id ) this.id = Math.guid();
    this.newRecord = false;
    this.parent.records[this.id] = this;
  }
});

Now, any newly created records have random GUIDs as their ID:

var asset = Asset.init();
asset.save();

asset.id //=> "54E52592-313E-4F8B-869B-58D61F00DC74"

If you’ve been observing closely, you might have spotted a bug relating to the references in our ORM. We’re not cloning instances when they’re returned by find() or when we’re saving them, so if we change any properties, they’re changed on the original asset. This is a problem because we only want assets to update when we call the update() function:

var asset = Asset.init({name: "foo"});
asset.save();

// Assert passes correctly
assertEqual( Asset.find(asset.id).name, "foo" );

// Let's change a property, but not call update()
asset.name = "wem";

// Oh dear! This assert fails, as the asset's name is now "wem"
assertEqual( Asset.find(asset.id).name, "foo" );

Let’s fix that by creating a new object during the find() operation. We’ll also need to duplicate the object whenever we create or update the record:

Model.extend({
  find: function(id){
    var record = this.records[id];
    if ( !record ) throw("Unknown record");
    return record.dup();
  }
});

Model.include({
  create: function(){
    this.newRecord = false;
    this.parent.records[this.id] = this.dup();
  },

  update: function(){
    this.parent.records[this.id] = this.dup();
  },

  dup: function(){
    return jQuery.extend(true, {}, this);
  }
});

We have another problem—Model.records is an object shared by every model:

assertEqual( Asset.records, Person.records );

This has the unfortunate side effect of mixing up all the records:

var asset = Asset.init();
asset.save();

assert( asset in Person.records );

The solution is to set a new records object whenever we create a new model. Model.created() is the callback for new object creation, so we can set any objects that are specific to the model in there:

Model.extend({
  created: function(){
    this.records = {};
  }
});

Unless your web application is entirely restricted to the browser, you’ll need to load in remote data from a server. Typically, a subset of data is loaded when the application starts, and more data is loaded after the interaction. Depending on the type of application and the amount of data, you may be able to load everything you need on the initial page load. This is ideal, so users never have to wait for more data to be loaded. However, this isn’t feasible for a lot of applications because there’s too much data to fit comfortably in a browser’s memory.

Preloading data is crucial to making your application feel slick and fast to your users, keeping any waiting time to a minimum. However, there’s a fine line between preloading data that’s actually accessed and loading redundant data that’s never used. You need to predict what sort of data your users will want (or use metrics once your application is live).

If you’re displaying a paginated list, why not preload the next page so transitions are instant? Or, even better, just display a long list and automatically load and insert data as the list is scrolled (the infinite scroll pattern). The less latency a user feels, the better.

When you do fetch new data, make sure the UI isn’t blocked. Display some sort of loading indicator, but make sure the interface is still usable. There should be very few scenarios, if any, that require blocking the UI.

Data can be present inline in the initial page or loaded with separate HTTP requests through Ajax or JSONP. Personally, I would recommend the latter two technologies, as including a lot of data inline increases the page size, whereas parallel requests load faster. AJAX and JSON also let you cache the HTML page, rather than dynamically render it for every request.

<script type="text/javascript">
  var User = {};
  User.records = <%= raw @users.to_json %>;
</script>

<script type="text/javascript">
  var User = {};
  User.records = [{"first_name": "Alex"}];
</script>

jQuery.ajax({
  url: "/ajax/endpoint",
  type: "GET",
  success: function(data) {
    alert(data);
  }
});

jQuery.get("/ajax/endpoint", function(data){
  $(".ajaxResult").text(data);
});

jQuery.get("/ajax/endpoint", {foo: "bar"}, function(data){
  /* ... */
});

jQuery.getJSON("/json/endpoint", function(json){
  /* ... */
});

jQuery.post("/users", {first_name: "Alex"}, function(result){
  /* Ajax POST was a success */
});

Access-Control-Allow-Origin: example.com
Access-Control-Request-Method: GET,POST

Access-Control-Request-Headers: Authorization

var req = new XMLHttpRequest();
req.open("POST", "/endpoint", true);
req.setRequestHeader("Authorization", oauth_signature);

<script src="http://example.com/data.json"> </script>

jsonCallback({"data": "foo"})

window.jsonCallback = function(result){
  // Do stuff with the result
}

jQuery.getJSON("http://example.com/data.json?callback=?", function(result){
  // Do stuff with the result
});

Populating our ORM with data is pretty straightforward. All we need to do is fetch the data from the server and then update our model’s records. Let’s add a populate() function to the Model object, which will iterate over any values given, create instances, and update the records object:

Model.extend({
  populate: function(values){
    // Reset model & records
    this.records = {};

    for (var i=0, il = values.length; i < il; i++) {
      var record = this.init(values[i]);
      record.newRecord = false;
      this.records[record.id] = record;
    }
  }
});

Now, we can use the Model.populate() function with the result of our request for data:

jQuery.getJSON("/assets", function(result){
  Asset.populate(result);
});

Any records the server returned will now be available in our ORM.

In the past, local data storage was a pain in the neck. The only options available to use were cookies and plug-ins like Adobe Flash. Cookies had an antiquated API, couldn’t store much data, and sent all the data back to the server on every request, adding unnecessary overhead. As for Flash, well, let’s try and steer clear of plug-ins if possible.

Fortunately, support for local storage was included in HTML5 and is implemented in the major browsers. Unlike cookies, data is stored exclusively on the client side and is never sent to servers. You can also store a great deal more data—the maximum amount differs per browser (and version number, as listed below), but they all offer at least 5 MB per domain:

HTML5 storage comes under the HTML5 Web Storage specification, and consists of two types: local storage and session storage. Local storage persists after the browser is closed; session storage persists only for the lifetime of the window. Any data stored is scoped by domain and is only accessible to scripts from the domain that originally stored the data.

You can access and manipulate local storage and session storage using the localStorage and sessionStorage objects, respectively. The API is very similar to setting properties on a JavaScript object and, apart from the two objects, is identical for both local and session storage:

// Setting a value
localStorage["someData"] = "wem";

There are a few more features to the WebStorage API:

// How many items are stored
var itemsStored = localStorage.length;

// Set an item (aliased to a hash syntax)
localStorage.setItem("someData", "wem");

// Get a stored item, returning null if unknown
localStorage.getItem("someData"); //=> "wem";

// Delete an item, returning null if unknown
localStorage.removeItem("someData");

// Clear all items
localStorage.clear();

Data is stored as strings, so if you intend on saving any objects or integers, you’ll have to do your own conversion. To do this using JSON, serialize the objects into JSON before you save them, and deserialize the JSON strings when fetching them:

var object = {some: "object"};

// Serialize and save an object
localStorage.setItem("seriData", JSON.stringify(object));

// Load and deserialize an object
var result = JSON.parse(localStorage.getItem("seriData"));

If you go over your storage quota (usually 5 MB per host), a QUOTA_EXCEEDED_ERR will be raised when saving additional data.

Let’s add local storage support to our ORM so that records can be persisted between page refreshes. To use the localStorage object, we need to serialize our records into a JSON string. The problem is that, at the moment, serialized objects look like this:

var json = JSON.stringify(Asset.init({name: "foo"}));
json //=> "{"parent":{"parent":{"prototype":{}},"records":[]},"name":"foo"}"

So, we need to override JSON’s serialization of our models. First, we need to determine which properties need to be serialized. Let’s add an attributes array to the Model object, which individual models can use to specify their attributes:

Model.extend({
  created: function(){
    this.records = {};
    this.attributes = [];
  }
});

Asset.attributes = ["name", "ext"];

Because every model has different attributes—and therefore can’t share the same array reference—the attributes property isn’t set directly on the Model. Instead, we’re creating a new array when a model is first created, similar to what we’re doing with the records object.

Now, let’s create an attributes() function, which will return an object of attribute names to values:

Model.include({
  attributes: function(){
    var result = {};
    for(var i in this.parent.attributes) {
      var attr = this.parent.attributes[i];
      result[attr] = this[attr];
    }
    result.id = this.id;
    return result;
  }
});

Now, we can set an array of attributes for every model:

Asset.attributes = ["name", "ext"];

And the attributes() function will return an object with the correct properties:

var asset = Asset.init({name: "document", ext: ".txt"});
asset.attributes(); //=> {name: "document", ext: ".txt"};

As for the overriding of JSON.stringify(), all that’s needed is a toJSON() method on model instances. The JSON library will use that function to find the object to serialize, rather than serializing the records object as-is:

Model.include({
  toJSON: function(){
    return(this.attributes());
  }
});

Let’s try serializing the records again. This time, the resultant JSON will contain the correct properties:

var json = JSON.stringify(Asset.records);
json //= "{"7B2A9E8D...":"{"name":"document","ext":".txt","id":"7B2A9E8D..."}"}"

Now that we’ve got JSON serializing working smoothly, adding local storage support to our models is trivial. We’ll add two functions onto our Model: saveLocal() and loadLocal(). When saving, we’ll convert the Model.records object into an array, serialize it, and send it to localStorage:

Model.LocalStorage = {
  saveLocal: function(name){
    // Turn records into an array
    var result = [];
    for (var i in this.records)
      result.push(this.records[i])

    localStorage[name] = JSON.stringify(result);
  },

  loadLocal: function(name){
    var result = JSON.parse(localStorage[name]);
    this.populate(result);
  }
};

Asset.extend(Model.LocalStorage);

It’s probably a good idea for the records to be read from the local storage when the page loads and to be saved when the page is closed. That, however, will be left as an exercise for the reader.

Earlier, we covered how to use jQuery’s post() function to send data to the server. The function takes three arguments: the endpoint URL, request data, and a callback:

jQuery.post("/users", {first_name: "Alex"}, function(result){
  /* Ajax POST was a success */
});

Now that we have an attributes() function, creating records to the server is simple—just POST the record’s attributes:

jQuery.post("/assets", asset.attributes(), function(result){
  /* Ajax POST was a success */
});

If we’re following REST conventions, we’ll want to do an HTTP POST when creating a record and a PUT request when updating the record. Let’s add two functions to Model instances—createRemote() and updateRemote()—which will send the correct HTTP request type to our server:

Model.include({
  createRemote: function(url, callback){
    $.post(url, this.attributes(), callback);
  },

  updateRemote: function(url, callback){
    $.ajax({
      url:     url,
      data:    this.attributes(),
      success: callback,
      type:    "PUT"
    });
  }
});

Now if we call createRemote() on an Asset instance, its attributes will be POSTed to the server:

// Usage:
Asset.init({name: "jason.txt"}).createRemote("/assets");