Backbone ViewModel vs (Data) Model

Question

In backbone I can use my models in different ways.

As I understand, a (Data) model is used to store data (possibly served from a RESTful web server) and a ViewModel is used to store information about a specific view (The views hidden/shown state for example).

Most of my knowledge is from this SO question.

After reading this article where the author says:

Render UI Upon Data Change, Not User Interaction

and

The flow is : User interaction -> data change -> view render.

For instance, if we are writing a play/pause toggle button in an audio player, the flow would be:

• The user hits ‘play’
• The model (data) state changes to ‘playing’
• The view renders in ‘playing’ mode

Following this pattern ensures that changes to the state triggered from other sources (such as fast forward, new playlist, network error, etc.) will toggle our button to do the right thing. In other words, we have a single source of truth: whenever our model changes we know we should render our button.

var PlayPauseButton = Backbone.View.extend({
  tagName: 'li',
  className: 'icon',
  initialize: function(){
    this.model.on('change:status', this.render, this);
  },
  render: function(){
    this.$el.removeClass('icon-play').removeClass('icon-pause');
    this.$el.addClass('icon-' + (this.isPlaying() ? 'pause' : 'play'));
  },
  events: {
    'click': function(){
      this.model.set('status', this.isPlaying() ? 'paused' : 'playing');
    }
  },
  isPlaying: function(){
    return this.model.get('status') === 'playing';
  }
});

I started to wonder the advantages and disadvantages of using each one.

Assuming we only have one model per view (I know we could have more, but if we limit it to one). I can think of,

ViewModel pros:

• The ones mentioned in the article.
  • Information about a view is saved in a model, preventing the view being cluttered.
  • State information can be shared between views.

cons:

• Cannot call Backbone's save() method because this will cause the model to save incorrect data to the server (the views state for example).
• Cannot call Backbone's fetch() method easily because we might trample our views data.

(Data) Model pros:

• Use backbone's built in save, fetch etc.
• views can share data without worrying about view specific data being stored in them.

cons:

• Models can only be used for data

Am I correct in thinking this?

Should I have a model for my data and a model for my view?

How does this work with collections?

I know Backbone is very loose and there are no hard and fast rules. But, does anybody have any real world experience of using one or the other? Or possibly both?

Any help is appreciated.

Answer 1

You're actually assuming you can't use your Data(Domain) models in the back end and that you need to deal with your data as ViewModel objects. The way I've been taught to do it by seasoned professionals of the Stack Overflow realm is:

1.) Always use ViewModels for views. Don't use Domain models. Domain models are often not completely suitable for views and this leads to people using magic strings, request caching and even sessions to store view-specific information, all of which is unnecessary.

2.) Due to this limiting you in the ways you've pointed out such as not being able to use data model methods built into Backbone, use an object mapper, either of your own creation or one someone else made earlier, to map the properties of the ViewModel to the properties of the Data model when you need to use it.

This allows you to have highly specific ViewModels without needing to worry about not being able to use Backbone's own Data models.

Regarding your slightly separate question about collections, you should store collections of ViewModel objects for other things you need. For example, if you have a list of Cars, you should provide your CarListViewModel with a list of CarViewModel objects. Should you choose to use Data objects when you get this far down the ladder of models it has lower impact, but should still be avoided.