Best practice regarding StateManager in Ember.js

Question

The StateManager in Ember.js isn't that well documented yet, so I've got some questions regarding its usage.

1. Should one strive to call .goToState only from within the state manager?
2. I sometimes find myself mirroring methods in the state manager on the view, e.g. save: -> StateManager.send("save"). Does that make sense or am I missing something?
3. Should all modification of models (generally) go through the state manager?
4. If one view has different states, should that be modeled using a ViewState with child states, or should I use computed properties and view properties to hold that information only in the view (without the state manager knowing of the views internal state)?*

*One example could be a three-step form, where the same template is used for all states but different areas are shown/hidden in the three steps.

Github reference: https://github.com/emberjs/ember.js/tree/master/packages/ember-states/lib

Answer 1

Regarding your point 2:

I sometimes find myself mirroring methods in the state manager on the view, e.g. save: -> StateManager.send("save"). Does that make sense or am I missing something?

You could use the action helper in your Handlebars template and set your StateManager as target

{{action "send" target="App.stateManager"}}

And the the send event is send to your App.stateManager.

Answer 2

Should one strive to call .goToState only from within the state manager?

Probably. I don't know this for certain, but it seems to me that because the state manager knows what state you're in, it's the place to enforce legal state transitions. If you called .goToState from outside the state manager, you're doing it without really knowing what state you're in, and while that's sometimes OK (maybe it's a state you really can reach from any other state) it's not a great habit to be in.

I sometimes find myself mirroring methods in the state manager on the view, e.g. save: -> StateManager.send("save"). Does that make sense or am I missing something?

I like what pangratz has to say about this.

Should all modification of models (generally) go through the state manager?

The way I use statecharts, no. I've seen some people using statecharts as pretty much a complete replacement for the controller layer, however, and if that's how you're working, then yes, it should go through the state manager. The pattern is to avoid direct manipulation of models from views; whether it's a controller layer or a state manager in between seems like a moot point to me.

The way I use state charts, however, the state manager is made to manage the state of the application. It can play traffic manager for the modification of models if that modification will change the state of the application (e.g. if there's a progress indicator while an update completes), but it seems to me that model updates aren't part of its mandate; they belong to controllers.

If one view has different states, should that be modeled using a ViewState with child states, or should I use computed properties and view properties to hold that information only in the view (without the state manager knowing of the views internal state)?

I think the state manager needs to know (or ought to know) the view's internal state.

Out of curiosity, are you coming from a web development background, or a desktop/mobile app development background? I came from web development, and state charts were a new concept for me. I found it very useful to read the canonical State Chart paper by David Harel ('ware PDF!). It's surprisingly readable for an academic paper and lays out the basic state chart concept most of the SproutCore/Ember world has been using since late 2010 (i.e. it's what Michael Cohen had in mind when he wrote Ki.)