Backbone.js - where to store state information?

Question

I'm new to Backbone.js , and I'm trying to figure out where state variables should live . My use case:

I have an application that provides a reading interface for a book (I know, classic example, right?). My models are Book and Page with collection classes for each. The structure of the application looks roughly like this (forgive the ASCII visio):

+------------+
| Controller |
+------------+
    |      Views                 Models
    | +--------------+      +----------------+
    |-|  IndexView   |------| BookCollection |
    | +--------------+      +----------------+
    |                               |
    | +--------------+      +----------------+
    +-|   BookView   |------|     Book       |
      +--------------+      +----------------+
       |                            |
       | +--------------+           |
       |-|  TitleView   |-+         |
       | +--------------+ | +----------------+
       |                  +-|     Page       |
       | +--------------+ | +----------------+ 
       +-|   PageView   |-+
         +--------------+ 

That is, the Controller instantiates and coordinates two views, IndexView and BookView , backed by the models. The BookView instantiates and coordinates a set of subviews (there are actually more than shown here).

State information includes:

• the current book (pointer or id)
• the current page (pointer or id)
• other UI state variables, such as whether images on the page are visible or not, whether other widgets are open or closed, etc.

My question is, where should this state information live? Possible options include:

• The models , which could be state-aware. This makes some sense, since they're intended to store data and views could listen for state changes, but it doesn't seem like this fits the intended Backbone.js pattern, and wouldn't always make sense (eg turning image on in the PageView should apply to all pages, not just the current one)

• A special singleton model intended to hold state information. Again, makes sense, easy to listen to, all the views could bind to it - but again, this seems outside standard MVC.

• The views , who are responsible for the UI state - but this would require views to be aware of each other to get state info, which seems incorrect

• The controller , which should route the application between states - this makes sense, but it implies a slightly odd round trip, eg User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View (rather than the simpler User selects "Show Images" --> View event listener is called --> View updates )

I guess in some ways this is a generic MVC question, but I'm having trouble getting my head around it. What part of the application should be responsible for saving the current state?

UPDATE: For future reference, I used a global singleton State model for this problem. The UI flow goes like this:

1. View UI handlers do nothing but update app.State
2. My routers also do nothing but update app.State - they're essentially specialized views that display and react to URL changes
3. Views listen to changes on app.State and update accordingly

My app is Open Source - you can see the code on Github . The relevant piece here is the State model , which I've extended to deal with (de)serializing state for the URL.

Answer 1

Don't limit your Backbone apps to Backbone constructs . If you find that your app needs some functionality that doesn't fit well into one of Backbone's constructs, don't shoehorn it into one just for the sake of keeping everything in Backbone.

I've found this backbone boilerplate to be helpful in this respect. It sets up modules for you and provides you with an app object that extends Backbone.Events (like in the previously-linked article). This app object can be used to store instantiated models, views and controllers/routers, and you should feel free to add your own non-backbone modules to the app object, to take care of responsibilities that don't fit perfectly into one of the Backbone constructs.

Answer 2

Why don't create a state model to store and describe the current state? I don't think that is wrong. Since the current state involves more than one model I think it's reasonable to create a state model to store and receive the current state.

The controller could then communicate with the state model to get the current state. The UI states should be stored in the corresponding model though. The state model knows which book and which page and then the book and page models keep track of their current UI states.