Backbone.js state management / view initialization based on url fragment

I'm trying to keep track of the state in this app using Backbone.js:

I have a "ChartAppModel" with a set of defaults:

ChartAppModel = Backbone.Model.extend({

defaults: { 
    countries : [], 
    selectedCountries : [],
    year : 1970,
},

initialize: function() { 
    loadAbunchOfData();
    checkStartState();
}

});

If given a start fragment, this default state should however be overwritten:

var startState = $.deparam.fragment(); //using Ben Alman's BBQ plugin
this.set({selectedCountries: startState.s, year: startState.y});

Now, for example the SidebarView is ready to be updated:

ChartAppViewSidebar = Backbone.View.extend({

initialize: function(){
      this.model.bind("change:selectedCountries", this.render);
},

render : function(){
      [... render new sidebar with check boxes ...]
},

Problem is I also have an event handler on the sidebar that updates the model:

events: {
"change input[name=country]": "menuChangeHandler",
},

menuChangeHandler : function(){
      [... set selectedCountries on model ...]
},

So there will be a feedback loop ... And then, I'd also like a way of pushing a new state - so I listen to model changes:

ChartAppModel = Backbone.Model.extend({

initialize: function() { 
    this.bind("change", this.setState);
}

});

... and relatively soon this state-manager will collapse ...

Questions:

1) How do I init my views (for example "which checkboxes should be checked") based on the fragment? (any hints on best practices for state / start state that is not a typical "route" are appreciated)

2) How can I avoid m开发者_运维百科y views setting an attribute on the model which they themselves listen for?

3) How can I push a new state based on a part of the model?

Bonus :)

4) How would you lay out the code for the app described?

Thanks!

That is one well defined question!

There is a question over what is a model. I believe there is a definition floating around as to what constitutes a model in the backbone world, and I'm not sure your strategy is in keeping with that definition. Also you are storing the state in both the url, and the model. You can just store the state in the url, as I will explain.

If I was doing this, there would be 2 views. One for your app controls, and nested inside that one for your graph: GraphView, and AppView. The model will be the data your going to plot, not the state of the interface.

Use a controller to kick start the app view and also to process any interface state defined in the url.

There is a question about levers of state in Backbone. Traditional web applications used a link/url as the primary lever of state but all that is now changing. Here is one possible strategy:

Checkbox Change Event -> Update location fragment -> trigger route in controller -> update the view
Slider Change Event -> Update location fragment -> trigger route in controller -> update the view

The great thing about such a strategy is that it takes care of the case where urls are passed around or bookmarked

Url specified in address bar -> trigger route in controller -> update the view

I'll take a stab at a pseudo code example. For this, I will make some assumptions on the data: The data is the dog population over time (with a granularity of year), where the slider should have a lower and upper bound, and there volume data is too large to load it all to the client at once.

First let's look at the Model to represent the statistical data. For each point on the graph we need something like { population: 27000, year: 2003 } Lets represent this as

DogStatModel extends Backbone.Model ->

and a collection of this data will be

DogStatCollection extends Backbone.Collection ->
    model: DogStatModel
    query: null // query sent to server to limit results
    url: function() {
        return "/dogStats?"+this.query
    }

Now lets look at the controller. In this strategy I propose, the controller lives up to its name.

AppController extends Backbone.Controller ->
    dogStatCollection: null,
    appView: null,

    routes: {
         "/:query" : "showChart"
    },

    chart: function(query){
        // 2dani, you described a nice way in your question
        // but will be more complicated if selections are not mutually exclusive
        // countries you could have as countries=sweden;france&fullscreen=true
        queryMap = parse(query) //  
        if (!this.dogStatCollection) dogStatCollection = new DogStatCollection
        dogStatCollection.query = queryMap.serverQuery
        if (!this.appView) {
           appView = new AppView()
           appView.collection = dogStatCollection
        }
        appView.fullScreen = queryMap.fullScreen
        dogStatCollection.fetch(success:function(){
          appView.render()
        })            
    }

2) How can I avoid my views setting an attribute on the model which they themselves listen for?

You don't. Your model should be doing validation on any attributes you try to update so your view needs to listen in case your setting of the attribute failed or the validation changed the value.

What your view does is, it's tries to set a value on the model, the model then either sets it, changes the data and sets it, or rejects it. Your view needs to be updated accordingly.

3) How can I push a new state based on a part of the model?

// for each attribute
_.each(["attribute1", "attribute2", "attribute3", ...], _.bind(function(val) {
    // bind the change
    // bind the setState with `this` and the `value` as the first parameter
    this.bind("change:" + value, _.bind(this.setState, this, value));
}, this));