Developing Backbone.js Applications (2013)
Chapter 2. Fundamentals
Design patterns are proven solutions to common development problems that can help us improve the organization and structure of our applications. By using patterns, we benefit from the collective experience of skilled developers who have repeatedly solved similar problems.
Historically, developers creating desktop and server-class applications have had a wealth of design patterns available for them to lean on, but it’s only been in the last few years that such patterns have been applied to client-side development.
In this chapter, we’re going to explore the evolution of the Model-View-Controller (MVC) design pattern and get our first look at how Backbone.js allows us to apply this pattern to client-side development.
MVC
MVC is an architectural design pattern that encourages improved application organization through a separation of concerns. It enforces the isolation of business data (models) from user interfaces (views), with a third component (controllers) traditionally managing logic, user input, and coordination of models and views. The pattern was originally designed by Trygve Reenskaug while he was working on Smalltalk-80 (1979), where it was initially called Model-View-Controller-Editor. MVC was described in depth in the Gang of Four’s 1994 book Design Patterns: Elements of Reusable Object-Oriented Software, which played a role in popularizing its use.
Smalltalk-80 MVC
It’s important to understand the issues that the original MVC pattern was aiming to solve, as it has changed quite heavily since the days of its origin. Back in the 70s, graphical user interfaces were few and far between. An approach known as separated presentation began to be used to make a clear division between domain objects, which modeled concepts in the real world (such as a photo, a person), and the presentation objects that were rendered to the user’s screen.
The Smalltalk-80 implementation of MVC took this concept further and had the objective of separating out the application logic from the user interface. The idea was that decoupling these parts of the application would also allow the reuse of models for other interfaces in the application. There are some interesting points worth noting about Smalltalk-80’s MVC architecture:
§ A domain element was known as a model and was ignorant of the user interface (views and controllers).
§ Presentation was taken care of by the view and the controller, but there wasn’t just a single view and controller—a view-controller pair was required for each element being displayed on the screen, so there was no true separation between them.
§ The controller’s role in this pair was handling user input (such as keypresses and click events) and doing something sensible with them.
§ The Observer pattern was used to update the view whenever the model changed.
Developers are sometimes surprised when they learn that the Observer pattern (nowadays commonly implemented as a publish/subscribe system) was included as a part of MVC’s architecture decades ago. In Smalltalk-80’s MVC, the view and controller both observe the model: anytime the model changes, the views react. A simple example of this is an application backed by stock market data: for the application to show real-time information, any change to the data in its model should result in the view being refreshed instantly.
Martin Fowler has done an excellent job of writing about MVC’s origins, so if you are interested in further historical information about Smalltalk-80’s MVC, I recommend reading his work.
MVC Applied to the Web
The Web relies heavily on the HTTP protocol, which is stateless. This means that there is not a constantly open connection between the browser and server; each request instantiates a new communication channel between the two. Once the request initiator (such as a browser) gets a response, the connection is closed. This fact creates a completely different context when compared to the one of the operating systems on which many of the original MVC ideas were developed. The MVC implementation has to conform to the web context.
An example of a server-side web application framework that tries to apply MVC to the web context is Ruby on Rails, shown in Figure 2-1.
Figure 2-1. The Ruby on Rails framework
At its core are the three MVC components we would expect: the Model-View-Controller architecture. In Rails:
§ Models represent the data in an application and are typically used to manage rules for interacting with a specific database table. You generally have one table corresponding to one model with much of your application’s business logic living within these models.
§ Views represent your user interface, often taking the form of HTML that will be sent down to the browser. They’re used to present application data to anything making requests from your application.
§ Controllers offer the glue between models and views. Their responsibility is to process requests from the browser, ask your models for data, and then supply this data to views so that they may be presented to the browser.
Although there’s a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called Model2. Justifications for this include that Rails does not notify views from the model, and controllers just pass model data directly to the view.
That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it’s equally useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).
Other server-side implementations of MVC, such as the PHP Zend framework, also implement the Front Controller design pattern. This pattern layers an MVC stack behind a single point of entry. This single point of entry means that all HTTP requests (for example,http://www.example.com, http://www.example.com/whichever-page/, and so on) are routed by the server’s configuration to the same handler, independent of the URI.
When the Front Controller receives an HTTP request, it analyzes it and decides which class (controller) and method (action) to invoke. The selected controller action takes over and interacts with the appropriate model to fulfill the request. The controller receives data back from the model, loads an appropriate view, injects the model data into it, and returns the response to the browser.
For example, let’s say we have our blog on www.example.com and we want to edit an article (with id=43) and request http://www.example.com/article/edit/43.
On the server side, the Front Controller would analyze the URL and invoke the article controller (corresponding to the /article/ part of the URI) and its edit action (corresponding to the /edit/ part of the URI). Within the action there would be a call to, let’s say, the articles model and itsArticles::getEntry(43) method (43 corresponding to the /43 at the end of the URI). This would return the blog article data from the database for edit. The article controller would then load the (article/edit) view, which would include logic for injecting the article’s data into a form suitable for editing its content, title, and other (meta) data. Finally, the resulting HTML response would be returned to the browser.
As you can imagine, a similar flow is necessary with POST requests after we click a save button in a form. The POST action URI would look like /article/save/43. The request would go through the same controller, but this time the save action would be invoked (due to the /save/URI chunk), the articles model would save the edited article to the database with Articles::saveEntry(43), and the browser would be redirected to the /article/edit/43 URI for further editing.
Finally, if the user requested http://www.example.com/ the Front Controller would invoke the default controller and action (for example, the index controller and its index action). Within index action there would be a call to the articles model and itsArticles::getLastEntries(10) method, which would return the last 10 blog posts. The controller would load the blog/index view, which would have basic logic for listing the blog posts.
Figure 2-2 shows this typical HTTP request/response lifecycle for server-side MVC.
Figure 2-2. The HTTP request/response lifecycle for server-side MVC
The server receives an HTTP request and routes it through a single entry point. At that entry point, the Front Controller analyzes the request and invokes an action of the appropriate controller. This process is called routing. The action model is asked to return and/or save submitted data. The model communicates with the data source (for example, database or API). Once the model completes its work it returns data to the controller, which then loads the appropriate view. The view executes presentation logic (loops through articles and prints titles, content, etc.) using the supplied data. In the end, an HTTP response is returned to the browser.
Client-Side MVC and Single-Page Apps
Several studies have confirmed that improvements to latency can have a positive impact on the usage and user engagement of sites and apps. This is at odds with the traditional approach to web app development, which is very server-centric, requiring a complete page reload to move from one page to the next. Even with heavy caching in place, the browser still has to parse the CSS, JavaScript, and HTML and render the interface to the screen.
In addition to resulting in a great deal of duplicated content being served back to the user, this approach affects both latency and the general responsiveness of the user experience. A trend to improve perceived latency in the past few years has been to move toward building single-page applications (SPAs)—apps that after an initial page load, are able to handle subsequent navigations and requests for data without the need for a complete reload.
When a user navigates to a new view, the application requests additional content required for the view using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. Ajax, short for Asynchronous JavaScript and XML), makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.
SPAs can also take advantage of browser features like the History API to update the address shown in the location bar when moving from one view to another. These URLs also make it possible for users to bookmark and share a particular application state, without the need to navigate to completely new pages.
The typical SPA consists of smaller pieces of interface representing logical entities, all of which have their own UI, business logic, and data. A good example is a basket in a shopping web application that can have items added to it. This basket might be presented to the user in a box in the top-right corner of the page (see Figure 2-3).
Figure 2-3. A shopping basket forming a region of a single-page application
The basket and its data are presented in HTML. The data and its associated View in HTML change over time. There was a time when we used jQuery (or a similar DOM manipulation library) and a bunch of Ajax calls and callbacks to keep the two in sync. That often produced code that was not well structured or easy to maintain. Bugs were frequent and perhaps even unavoidable.
The need for fast, complex, and responsive Ajax-powered web applications demands replication of a lot of this logic on the client side, dramatically increasing the size and complexity of the code residing there. Eventually this has brought us to the point where we need MVC (or a similar architecture) implemented on the client side to better structure the code and make it easier to maintain and further extend during the application lifecycle.
Through evolution and trial and error, JavaScript developers have harnessed the power of the traditional MVC pattern, leading to the development of several MVC-inspired JavaScript frameworks, such as Backbone.js.
Client-Side MVC: Backbone Style
Let’s take our first look at how Backbone.js brings the benefits of MVC to client-side development using a todo application as our example. We will build on this example in the coming chapters when we explore Backbone’s features, but for now we will just focus on the core components’ relationships to MVC.
Our example will need a div element to which we can attach a list of todos. It will also need an HTML template containing a placeholder for a todo item title and a completion checkbox that can be instantiated for todo item instances. These are provided by the following HTML:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title></title>
<meta name="description" content="">
</head>
<body>
<div id="todo">
</div>
<script type="text/template" id="item-template">
<div>
<input id="todo_complete" type="checkbox" <%= completed ?
'checked="checked"' : '' %>>
<%- title %>
</div>
</script>
<script src="jquery.js"></script>
<script src="underscore.js"></script>
<script src="backbone.js"></script>
<script src="demo.js"></script>
</body>
</html>
In our Todo application (demo.js), Backbone model instances are used to hold the data for each todo item:
// Define a Todo model
var Todo = Backbone.Model.extend({
// Default todo attribute values
defaults: {
title: '',
completed: false
}
});
// Instantiate the Todo model with a title, allowing completed attribute
// to default to false
var myTodo = new Todo({
title: 'Check attributes property of the logged models in the console.'
});
Our Todo model extends Backbone.Model and simply defines default values for two data attributes. As you will discover in the upcoming chapters, Backbone models provide many more features, but this simple model illustrates that first and foremost a model is a data container.
Each todo instance will be rendered on the page by a TodoView:
var TodoView = Backbone.View.extend({
tagName: 'li',
// Cache the template function for a single item.
todoTpl: _.template( $('#item-template').html() ),
events: {
'dblclick label': 'edit',
'keypress .edit': 'updateOnEnter',
'blur .edit': 'close'
},
// Called when the view is first created
initialize: function () {
this.$el = $('#todo');
// Later we'll look at:
// this.listenTo(someCollection, 'all', this.render);
// but you can actually run this example right now by
// calling TodoView.render();
},
// Rerender the titles of the todo item.
render: function() {
this.$el.html( this.todoTpl( this.model.toJSON() ) );
// $el here is a reference to the jQuery element
// associated with the view, todoTpl is a reference
// to an Underscore template and toJSON() returns an
// object containing the model's attributes
// Altogether, the statement is replacing the HTML of
// a DOM element with the result of instantiating a
// template with the model's attributes.
this.input = this.$('.edit');
return this;
},
edit: function() {
// executed when todo label is double-clicked
},
close: function() {
// executed when todo loses focus
},
updateOnEnter: function( e ) {
// executed on each keypress when in todo edit mode,
// but we'll wait for enter to get in action
}
});
// create a view for a todo
var todoView = new TodoView({model: myTodo});
We define TodoView by extending Backbone.View and instantiate it with an associated model. In our example, the render() method uses a template to construct the HTML for the todo item, which is placed inside a li element. Each call to render() will replace the content of the lielement using the current model data. Thus, a view instance renders the content of a DOM element using the attributes of an associated model. Later we will see how a view can bind its render() method to model change events, causing the view to rerender whenever the model changes.
So far, we have seen that Backbone.Model implements the model aspect of MVC and Backbone.View implements the view. However, as we noted earlier, Backbone departs from traditional MVC when it comes to controllers—there is no Backbone.Controller!
Instead, the controller responsibility is addressed within the view. Recall that controllers respond to requests and perform appropriate actions, which may result in changes to the model and updates to the view. In an SPA, rather than having requests in the traditional sense, we have events. Events can be traditional browser DOM events (such as clicks) or internal application events (such as model changes).
In our TodoView, the events attribute fulfills the role of the controller configuration, defining how events occurring within the view’s DOM element are to be routed to event-handling methods defined in the View.
While in this instance events help us relate Backbone to the MVC pattern, we will see them playing a much larger role in our SPA applications. Backbone.Event is a fundamental Backbone component that is mixed into both Backbone.Model and Backbone.View, providing them with rich event management capabilities. Note that the traditional view role (Smalltalk-80-style) is performed by the template, not by the Backbone.View.
This completes our first encounter with Backbone.js. The remainder of this book will explore the many features of the framework that build on these simple constructs. Before moving on, let’s take a look at common features of JavaScript MV* frameworks.
Implementation Specifics
An SPA is loaded into the browser through a normal HTTP request and response. The page may simply be an HTML file, as in the preceding example, or it could be a view constructed by a server-side MVC implementation.
Once the SPA is loaded, a client-side router intercepts URLs and invokes client-side logic in place of sending a new request to the server. Figure 2-4 shows typical request handling for client-side MVC as implemented by Backbone.
Figure 2-4. Backbone’s approach to request handling
URL routing, DOM events (such as mouse clicks), and model events (such as attribute changes) all trigger handling logic in the view. The handlers update the DOM and models, which may trigger additional events. Models are synced with data sources, which may involve communicating with backend servers.
Models
§ The built-in capabilities of models vary across frameworks; however, it’s common for them to support validation of attributes, where attributes represent the properties of the model, such as a model identifier.
§ When using models in real-world applications we generally also need a way of persisting models. Persistence allows us to edit and update models with the knowledge that their most recent states will be saved somewhere—for example, in a web browser’s localStorage datastore or synchronized with a database.
§ A model may have multiple views observing it for changes. By observing, I mean that a view has registered an interest in being informed whenever an update is made to the model. This allows the view to ensure that what is displayed on screen is kept in sync with the data contained in the model. Depending on your requirements, you might create a single view displaying all model attributes, or create separate views displaying different attributes. The important point is that the model doesn’t care how these views are organized; it simply announces updates to its data as necessary through the framework’s event system.
§ It is not uncommon for modern MVC/MV* frameworks to provide a means of grouping models together. In Backbone, these groups are called collections. Managing models in groups allows us to write application logic based on notifications from the group when a model within the group changes. This avoids the need to manually observe individual model instances. We’ll see this in action later in the book. Collections are also useful for performing any aggregate computations across more than one model.
Views
§ Users interact with views, which usually means reading and editing model data. For example, in our Todo application, Todo model viewing happens in the user interface in the list of all todo items. Within it, each todo is rendered with its title and completed checkbox. Model editing is done through an edit view, where a user who has selected a specific todo edits its title in a form.
§ We define within our view a render() utility, which is responsible for rendering the contents of the Model using a JavaScript templating engine (provided by Underscore.js) and updating the contents of our view, referenced by this.el.
§ We then add our render() callback as a model subscriber, so the view can be triggered to update when the model changes.
§ You may wonder where user interaction comes into play here. When users click on a todo element within the view, it’s not the view’s responsibility to know what to do next. A controller makes this decision. In Backbone, we achieve this by adding an event listener to the todo’s element, which delegates handling of the click to an event handler.
Templating
In the context of JavaScript frameworks that support MVC/MV*, it is worth looking more closely at JavaScript templating and its relationship to views.
It has long been considered bad practice (and computationally expensive) to manually create large blocks of HTML markup in-memory through string concatenation. Developers using this technique often find themselves iterating through their data, wrapping it in nested divs and using outdated techniques such as document.write to inject the template into the DOM. This approach often means keeping scripted markup inline with standard markup, which can quickly become difficult to read and maintain, especially when you’re building large applications.
JavaScript templating libraries (such as Mustache or Handlebars.js) are often used to define templates for views as HTML markup containing template variables. These template blocks can be either stored externally or within <script> tags with a custom type (such as text/template). Variables are delimited through a variable syntax (for example, <%= title %> for Underscore and {{title}} for Handlebars).
JavaScript template libraries typically accept data in a number of formats, including JSON, a serialization format that is always a string. The grunt work of populating templates with data is generally taken care of by the framework itself. This has several benefits, particularly when you opt to store templates externally, which enables applications to load templates dynamically on an as-needed basis.
Let’s compare two examples of HTML templates. One is implemented using the popular Handlebars.js library, and the other uses Underscore’s microtemplates.
Handlebars.js
<div class="view">
<input class="toggle" type="checkbox" {{#if completed}} "checked" {{/if}}>
<label>{{title}}</label>
<button class="destroy"></button>
</div>
<input class="edit" value="{{title}}">
Underscore.js microtemplates
<div class="view">
<input class="toggle" type="checkbox" <%= completed ? 'checked' : '' %>>
<label><%- title %></label>
<button class="destroy"></button>
</div>
<input class="edit" value="<%= title %>">
NOTE
It is also worth noting that in classical web development, navigating between independent views required the use of a page refresh. In single-page JavaScript applications, however, once data is fetched from a server via Ajax, it can be dynamically rendered in a new view within the same page. Since this doesn’t automatically update the URL, the role of navigation thus falls to a router, which assists in managing application state (e.g., allowing users to bookmark a particular view they have navigated to). As routers are neither a part of MVC nor present in every MVC-like framework, I will not be going into them in greater detail in this section.
Controllers
In our Todo application, a controller would be responsible for handling changes the user made in the edit view for a particular todo, updating a specific todo model when a user had finished editing.
It’s with controllers that most JavaScript MVC frameworks depart from the traditional interpretation of the MVC pattern. The reasons for this vary, but in my opinion, JavaScript framework authors likely initially looked at server-side interpretations of MVC (such as Ruby on Rails), realized that the approach didn’t translate 1:1 on the client side, and so reinterpreted the C in MVC to solve their state management problem. This was a clever approach, but it can make it hard for developers coming to MVC for the first time to understand both the classical MVC pattern and the proper role of controllers in other JavaScript frameworks.
So does Backbone.js have controllers? Not really. Backbone’s views typically contain controller logic, and routers are used to help manage application state, but neither are true controllers according to classical MVC.
In this respect, contrary to what might be mentioned in the official documentation or in blog posts, Backbone isn’t truly an MVC framework. It’s in fact better to view it a member of the MV* family that approaches architecture in its own way. There is, of course, nothing wrong with this, but it is important to distinguish between classical MVC and MV* should you be relying on discussions of MVC to help with your Backbone projects.
What Does MVC Give Us?
To summarize, the MVC pattern helps you keep your application logic separate from your user interface, making it easier to change and maintain both. Thanks to this separation of logic, it is more clear where changes to your data, interface, or business logic need to be made and for what your unit tests should be written.
Delving Deeper into MVC
Right now, you likely have a basic understanding of what the MVC pattern provides, but for the curious, we’ll explore it a little further.
The GoF (Gang of Four) do not refer to MVC as a design pattern, but rather consider it a set of classes to build a user interface. In their view, it’s actually a variation of three other classical design patterns: the Observer (publish/subscribe), Strategy, and Composite patterns. Depending on how MVC has been implemented in a framework, it may also use the Factory and Decorator patterns. I’ve covered some of these patterns in my other book, JavaScript Design Patterns for Beginners, if you would like to read about them further.
As we’ve discussed, models represent application data, while views handle what the user is presented with on screen. As such, MVC relies on publish/subscribe for some of its core communication (something that surprisingly isn’t covered in many articles about the MVC pattern). When a model is changed, it publishes to the rest of the application that it has been updated. The subscriber, generally a controller, then updates the view accordingly. The observer-viewer nature of this relationship is what facilitates multiple views being attached to the same model.
For developers interested in knowing more about the decoupled nature of MVC (once again, depending on the implementation), one of the goals of the pattern is to help define one-to-many relationships between a topic and its observers. When a topic changes, its observers are updated. Views and controllers have a slightly different relationship. Controllers facilitate views’ responses to different user input and are an example of the Strategy pattern.
Summary
Having reviewed the classical MVC pattern, you should now understand how it allows developers to cleanly separate concerns in an application. You should also now appreciate how JavaScript MVC frameworks may differ in their interpretation of MVC, and how they share some of the fundamental concepts of the original pattern.
When reviewing a new JavaScript MVC/MV* framework, remember that it can be useful to step back and consider how it’s opted to approach models, views, controllers, or other alternatives, as this can better help you understand how the framework is intended to be used.
Further Reading
If you are interested in learning more about the variation of MVC that Backbone.js uses, please see MVP.
Fast Facts
Backbone.js
§ Contains these core components: model, view, collection, router. Enforces its own flavor of MV*.
§ Supports event-driven communication between views and models. As we’ll see, it’s relatively straightforward to add event listeners to any attribute in a model, giving developers fine-grained control over what changes in the view.
§ Supports data bindings through manual events or a separate Key-value observing (KVO) library.
§ Offers support for RESTful interfaces out of the box, so models can be easily tied to a backend.
§ Possesses an extensive eventing system. It’s trivial to add support for Publish/Subscribe in Backbone.
§ Instantiates prototypes with the new keyword, which some developers prefer.
§ Is agnostic about templating frameworks; however, Underscore’s microtemplating is available by default.
§ Provides clear and flexible conventions for structuring applications. Backbone doesn’t force usage of all of its components and can work with only those needed.
Used by
Disqus
Disqus chose Backbone.js to power the latest version of its commenting widget (shown in Figure 2-5). It felt it was the right choice for its distributed web app, given Backbone’s small footprint and ease of extensibility.
Figure 2-5. The Disqus discussion widget
Khan Academy
Offering a web app that aims to provide free world-class education to anyone anywhere, Khan uses Backbone to keep its frontend code both modular and organized (Figure 2-6).
Figure 2-6. The Khan Academy Knowledge Map
MetaLab
MetaLab created Flow, a task management app for teams using Backbone (Figure 2-7). Its workspace uses Backbone to create task views, activities, accounts, tags, and more.
Figure 2-7. The Flow online task management application
Walmart Mobile
Walmart chose Backbone to power its mobile web applications (Figure 2-8), creating two new extension frameworks in the process: Thorax and Lumbar. We’ll be discussing both of these later in the book.
Figure 2-8. Walmart Mobile
Airbnb
Airbnb (Figure 2-9) developed its mobile web app using Backbone and now uses it across many of its products.
Figure 2-9. The Airbnb home page
Code School
Code School’s course challenge app (Figure 2-10) was built from the ground up using Backbone, taking advantage of all the pieces it has to offer: routers, collections, models, and complex event handling.
Figure 2-10. The Code School learning environment