Preferred pattern for master-detail scenario in Backbone.js
===

The majority of Backbone tutorials that deal with master-detail scenarios handle the detail  state by creating new views with models passed from routes ([example][1]). I'm wondering what the alternative options are what the pros and cons are for each.

The thing that has always stood out to me about this approach of instantiating new views is that it seems like a missed opportunity to make use of Backbone's model-view binding. I.e., create a single detail view that updates based on the selected model. But this would require a separate model concerned only with the UI / active state.

I can think of three different patterns:

* Create/Destroy views for each active detail. (This seems like excess work, not to mention potential [zombie problems][2])
* Maintain an additional model that represents the active detail and create one view that re-renders itself when the model updates
* Create one view with a method that swaps out the associated model (I think this can lead to event binding problems and is probably not a good idea)

What are the pros/cons? Is the idea in #2 of using a UI model a bad practice? Are there other solutions? 


  [1]: http://coenraets.org/blog/2011/12/backbone-js-wine-cellar-tutorial-part-1-getting-started/
  [2]: http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/