Question

I’m using Backbone.js 0.9.2 from the Backbone-on-rails gem. I’m also trying to use the new ‘pushState’ instead of the old hash URL.

The Problem

I’m building a standard Rails like CRUD interface to keep track of my appointments. I have a ‘new’ link on the main index.jst.eco page:

<h1>Appointments</h1>
<p><a href="/appointments/new" class="new">New Appointment</a></p>

I load the page and click on that ‘new’ link and backbone fires off the event and doesn’t have to reload the whole page. Here is that event:

class BackboneOnRails.Views.AppointmentsIndex extends Backbone.View
  template: JST['appointments/index'],
  events: ->
    'click .new': 'newAppointment'

  newAppointment: ->
    Backbone.history.navigate("/appointments/new", {trigger: true})
    return false

  # The rest of the index methods omitted for brevity 

This then invokes the backbone router:

class BackboneOnRails.Routers.Appointments extends Backbone.Router
  routes:
    '': 'index'
    'appointments': 'index'
    'appointments/new': 'new'

  initialize: ->
    this.appointments = new BackboneOnRails.Collections.Appointments()
    this.appointmentsIndexView = new BackboneOnRails.Views.AppointmentsIndex({collection: this.appointments})
    this.appointmentsIndexView.render()

  index: ->
    $("#container").html(this.appointmentsIndexView.el)
    this.appointments.fetch()

  new: ->
    appointments = new BackboneOnRails.Collections.Appointments()
    view = new BackboneOnRails.Views.AppointmentNew({collection: appointments})
    $("#container").html(view.render().el)

The problem happens when I hit the browsers back button, then try using the ‘new’ link again. This time around it does a full reload of the page.

What is happening to the javascript bindings when I hit back on the browser?

I have a show event for the item and with that I can go back and forth no problem. I’ve compared both and they look like the same sort of calls.

Answer 1

The problem is in your attempted re-use of the appointmentsIndexView instance. Removing the view from the DOM destroys the DOM event handlers. Re-adding the view’s el to the DOM does not re-connect them.

Overview Of The Problem

When you load that view with the initialize and index methods of your router the first time, everything is fine because you have a fresh instance of the IndexView. The DOM events are attached to the view properly, and life is good.

When you hit the new route / method of your router, you’re effectively trying to remove the index view from the screen and replace it with the add new view. This works from a visual stand point and from the standpoint of the add new view.

When you hit the back button, though, you’re staying within the same live application instance in your browser tab. Hitting the back button with pushstate enabled tells the browser not to reload the entire app, just to update the url and fire off the router method for the index.

In this case, you’re index view is not re-built from the ground up. You’re re-using the same view instance, but re-loading it with data from the server. The data load works perfectly fine because your view and collection are still attached. The DOM event bindings fail, however, because they bindings were previously removed and not re-added.

2 Common Solutions

There are two common solutions for this, and many variations of these solutions.

1) Don’t re-use view instances.

This is my strongly recommended suggestion. In every instance where I have tried to re-use a view instance, I have consistently run into very large problems – including the exact problem you’re having.

Instead, re-create a new view instance every time you need to show the index of appointments. That means you create the new index view in your index method of the router, instead of the initialize method.

2) Clear and re-bind the DOM events

If, for some reason, you feel that you really need to re-use the view instance (which should never be true), you can solve it with some information that Tim Branyen posted on his blog a while back:

http://tbranyen.com/post/missing-jquery-events-while-rendering

I do not recommend this approach. Re-using a view instance might seem like a good idea off-hand, but it will lead down a bad path toward other problems, including bloated memory usage by leaving too many unused parts around in your app.

Side Note: Zombies And Memory Leaks

In either case – whether you decide to re-use view instances or re-create them when you need them – you’re likely to run in to some memory leaks.

In the case of re-using a view, you’re explicitly holding on to an object in memory when you don’t need to. This isn’t really a “leak” but it’s an excessive use of memory. You should de-reference the object when it’s not needed and re-create it when it is needed. This will cut down on memory usage and allow your app to perform better.

I have a blog post covering how this works, here: http://lostechies.com/derickbailey/2012/03/19/backbone-js-and-javascript-garbage-collection/

In the case of not re-using a view, you may wind up with a true memory leak by leaving model and collection event bindings hanging around after a view has been removed from the visible DOM. If you decide not to re-use your views, you will need to make your code that replaces the #container html more robust, and have it clean up the old view.

I’ve got a blog post detailing a solution for that, as well: http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/ – be sure to read the comments from Johnny Oshika in this post, as he points to a very useful StackOverflow answer where he shows a simple method of handling model and collection events.