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 my 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:
The great thing about such a strategy is that it takes care of the case where urls are passed around or bookmarked
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
and a collection of this data will be
Now lets look at the controller. In this strategy I propose, the controller lives up to its name.