[ville]

Could someone give a practical example of a use case for this? This is probably useful for some typical problems in Backbone applications but not something I knew I would need (having built a couple of non-trivial Backbone apps).

[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!

[mroseboom]

@ZackMaril points to a blog post where he discusses the potential benefits of a Backbone.Router that could provide state awareness to other application objects such as models. Scroll down to the Eidetic backbone section to read more. http://zacharymaril.com/blog/2012/07/10/ideas-about-future-o...

[zackzackzack]

Yep! It looks like if you hooked this up to the router with serialization function, you could embed state directly into the url without too much effort.

[camachgk]

One practical application could be a drop down in a view that is tied to a bunch of functionality and a route update. With two access points (user click or URL changes) to any of the drop down values and the associated behavior ("states"), StateManager provides a modular way for defining each of those states and handling the associated functionality for transitions.

[eranation]

If I understood correctly, seems it can be useful for a tour/wizard flow, that has a complex graph of options (user can exit at any time and next option is dependant on the previous choice, etc).

[politician]

You could think of it as an abstraction of the Router mechanism.

[danso]

Even if it's just that, that's greatly helpful, at least to me. I'm still not past the traditional page-loading model when thinking of how to go back and forth between routes.

[daftdevelopers]

With the additional ability to add specific functionality when moving between various states without a bunch of conditional checks.