Seems to me like this is reinventing parts of ember.js on top of Backbone. That's neat but when my apps need this sort of behavior I'm willing to be they will also need solutions to other common problems and I'd rather not reassemble a large framework out of disparate pieces to get that level of functionality. When do you decide that you have so many layers on top of Backbone that you have a custom stack no one else will understand?
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).
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.
@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...
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.
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).
zalambar|13 years ago
ville|13 years ago
Jare|13 years ago
- 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.
mroseboom|13 years ago
camachgk|13 years ago
eranation|13 years ago
politician|13 years ago
devinus|13 years ago