[Jare]

Useful to manage parts of your application (or the whole thing) as state machines. For example, a simple email app might have top-level states such as:

- list of folders

- contents of a given folder

- contents of a thread

- contents of a message

- compose message

- profile settings

- ...

In a typical MVC app, the 'enter' method of each state would set up the appropriate models, views and controllers, and the 'exit' method would do the corresponding teardown / cleanup. You could tie this to the history API (or history.js) to support URL linking and navigation.

But states can mean anything you want as long as only one of them can be active at any time in a given context (StateManager). In a Vim implementation you could manage the normal / insert / visual editing modes using States. In a space shooter game, you could have the player spaceship be in normal, shielded, dead, etc states.

The link to Backbone is extremely thin and basically limited to using Backbone's event system to trigger state change events.

[dchuk]

I'm very much a noob when it comes to Backbone, but isn't the states you described a use case for the built in router already included in Backbone?

[Jare]

You could use Backbone's routes to manage top-level app states if there is a 1:1 mapping between states and routes, your app's states are relatively simple, and you don't need any special handling of transitions. As bmelton describes, that case is not as common or obvious as one might think.

In general, I'd always encourage any non-trivial app to treat states and routes/history separately.

[bmelton]

That's treating the application as if it were completely stateless, and mucks with browser history. A good example of when to use state vs. a route is on a delete. If I route to a delete, for example, then it might fire again when I hit my 'back' button, which is obviously a bad idea.

Derick Bailey has a good article on it here: http://lostechies.com/derickbailey/2011/08/03/stop-using-bac...

[dchuk]

awesome, thanks!