Question

In the data-driven paradigm of Backbone, the backbone views/routers should subscribe to model changes and act based on the model change events. Following this principle, the application’s views/routers can be isolated from each other, which is great.

However, there are a lot of changes in the states of the applications that are not persisted in the models. For example, in a to-do app, there could be buttons that lets you look at tasks that are “completed”, “not completed”, or “all”. This is an application state not persisted in the model. Note that the completion state of any task is persisted, but the current filter in the view is a transient state.

What is a good way to deal with such application state? Using a plain, non-backboned state means that the views/routers cannot listen to the changes in this state, and hence become difficult to code in the data-driven paradigm.

Answer 1

Your buttons filter example can be properly solved using Model events.

I suppose your buttons handlers have access to the tasks Collection. Then filter the collection and trigger events over the selected Models like:

model.trigger( "filter:selected" )

or

model.trigger( "filter:un-selected" )

The ModelView can be listening to these events on its Model and acts accordingly.

This is following your requirements of respecting the not use or “attributes that are not persistent” like selected but I don’t have any trauma to use special attributes even if they shouldn’t be persistent. So I also suggest to modify the selected attribute of your Models to represent volatile states.

So in your buttons handlers filter the collection and modify the selected attribute in your Models is my preferred solution:

model.set( "selected", true )

You can always override Model.toJSON() to clean up before sync or just leave this special attributes to travel to your server and being ignored there.