Backbone.js Wine Cellar tutorial – Part 2: CRUD

In Part 1: Getting started of this tutorial, we set up the basic infrastructure for the Wine Cellar application. The application so far is read-only, and thus it only allows you to retrieve a list of wines and display the details of the wine you select.

In this second installment, you will add the ability to create, update, and delete (CRUD) wines.

A PHP version of these services (using the Slim framework) is available as part of the download. A similar Java version of the API (using JAX-RS) is available as part of this post.

Using Backbone.js with non-RESTful Services

If your persistence layer is not available through RESTful services, you can override Backbone.sync. From the documentation:

“Backbone.sync is the function that Backbone calls every time it attempts to read or save a model to the server. By default, it uses (jQuery/Zepto).ajax to make a RESTful JSON request. You can override it in order to use a different persistence strategy, such as WebSockets, XML transport, or Local Storage.”

I do not discuss using non-RESTful services in this tutorial. See the documentation for more information.

You can run the application that you will code in this tutorial.  The create, update, delete features are disabled in this online version.

Here is the code for Part 2. I discuss key changes below.

Code highlights

Wine (lines 2-14)

Part 2 adds two attributes to the Wine Model, as follows:

• urlRoot (line 3): The RESTful service endpoint to retrieve or persist Model data. Note that this attribute is only needed when retrieving/persisting Models that are not part of a Collection. If the Model is part of a Collection, the url attribute defined in the Collection is enough for Backbone.js to know how to retrieve, update, or delete data using your RESTful API.
• Defaults (line 4): Default values used when a new instance of the model is created. This attribute is optional. However, it was required in this application for the wine-details template to render an “empty” wine model object (which happens when adding a new wine).

WineListView (lines 22-40)

When user adds a new wine, you want it to automatically appear in the list. To make that happen, bind the View to the add event of the WineListView model (which is the collection of wines). When that event is fired, the application creates and adds a new instance of WineListItemView to the list.

WineListItemView (lines 42-62)

• When a user changes a wine, you want the corresponding WineListItemView to re-render automatically to reflect the change. To make that happen, bind the View to the change event of its model, and execute the render function when the event is fired. Similarly, when a user deletes a wine, you want the list item to be removed automatically.
• To make that happen, bind the view to the destroy event of its model and execute our custom close function when the event is fired.
  Important: To avoid memory leaks and events firing multiple times, it is important to unbind the event listeners before removing the list item from the DOM.
• Note that in either case you don’t have the overhead of re-rendering the entire list. You only re-render or remove the list item affected by the change.

WineView (lines 64-123)

In the spirit of encapsulation, the event handlers for the Save and Delete buttons are defined inside WineView, as opposed to defining them as free-hanging code blocks outside the “class” definitions. Use the Backbone.js Events syntax, which uses the jQuery delegate mechanism behind the scenes.

There are always different approaches to update the model based on user input in a form:

• “Real time” approach: You use the change handler to update the model as changes are made in the form. This is in essence bi-directional data binding. The model and the UI controls are always in sync. Using this approach, you can then choose between sending changes to the server in real time (implicit save), or wait until the user clicks a Save button (explicit save). The first option can be chatty and unpractical when there are cross-field validation rules. The second option may require you to undo model changes if the user navigates to another item without clicking Save.
• “Delayed” approach: You wait until the user clicks Save to update the model based on the new values in UI controls and then send the changes to the server.

This discussion is not specific to Backbone.js and is therefore beyond the scope of this post. For simplicity, I used the delayed approach here. However I still wired the change event, and use it to log changes to the console. I found this very useful when debugging the application, and particularly to make sure I had cleaned up my bindings (see the close function).  If you see the change event firing multiple times, you probably didn’t clean up your bindings appropriately.

HeaderView (lines 125-148)

Backbone.js Views are typically used to render domain models (as done in WineListView, WineListItemView, and Wine View). But they can also be used to create composite UI components. For example, in this application, we define a Header View (a toolbar) that could be made of different components and which encapsulates its own logic.

The application so far doesn’t support deep-linking. For example, it doesn’t include the functionality to select a wine in the list, grab the URL in the address bar and paste it in another browser window: these features don’t yet work. In Part 3: Deep linking and application states, you will add complete support for deep linking.