amberjs/amber.js — comment on commit 4ae2fbd5a5fc99aac0a31d2f95f12dfbe61bb939
File:  line 0
By tomdale:

Scott,

States should (by definition) be stateless. If you think about it, the sum of the current state object, plus all of its parent states, should capture the precise state of the application. By definition, if your state object has its own state, then both the current state object PLUS that state is necessary to describe what state the application is in, thus succumbing to the chaos that we had before state managers.

I liked the storyboard and sheet names but in practice they were massively confusing to developers, especially those who have iOS experience. In particular, most applications will have "sheets" (SC.ViewStates) as top-level states, and each sheet will have sub-states that it cycles through as the user interacts with that particular UI. There just wasn't good "synergy" between storyboard/sheet/state. :P

Additionally, stateless states allow you to only have to create one hierarchy to share between potentially thousands of objects. This will allow us to eat our own dogfood by using this state manager internally in the framework's view code and the forthcoming data layer.

I think a sample application with diagrams describing how the state managers are set up will be useful. We should have one in the next few weeks that clarifies this stuff.