javascript - Ember.js 中有关 StateManager 的最佳实践

Question

Ember.js 中的 StateManager 还没有很好的文档记录，所以我对它的用法有一些疑问。

1. 是否应该努力仅从状态管理器内部调用 .goToState？
2. 有时我发现自己在 View 的状态管理器中镜像方法，例如保存:-> StateManager.send("save")。这有意义吗？还是我遗漏了什么？
3. 模型的所有修改(通常)都应该通过状态管理器吗？
4. 如果一个 View 有不同的状态，是否应该使用带有子状态的 ViewState 进行建模，或者我应该使用计算属性和 View 属性仅在 View 中保存该信息(没有状态管理器了解 View 内部状态)？*

*一个示例可以是一个三步表单，其中所有状态使用相同的模板，但在三个步骤中显示/隐藏不同的区域。

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

Answer 1

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

可能吧。我不确定这一点，但在我看来，因为状态管理器知道你处于什么状态，所以它是执行合法状态转换的地方。如果您从状态管理器外部调用 .goToState，那么您实际上并不知道自己处于什么状态，虽然这有时没问题(也许这是您真正可以从任何其他状态达到的状态)，但这不是一个好习惯进入。

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?

我喜欢 pangratz 对此所说的话。

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

我使用状态图的方式，不。我见过一些人使用状态图来完全替代 Controller 层，但是，如果这就是您的工作方式，那么是的，它应该通过状态管理器。该模式是为了避免直接从 View 中操作模型；无论是 Controller 层还是中间的状态管理器，对我来说似乎都是一个有争议的问题。

然而，我使用状态图的方式是让状态管理器来管理应用程序的状态。如果修改会改变应用程序的状态(例如，如果在更新完成时有进度指示器)，它可以为模型的修改充当流量管理器，但在我看来，模型更新不是其任务的一部分；他们属于 Controller 。

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)?

我认为状态管理器需要知道(或者应该知道) View 的内部状态。

出于好奇，您是来自网络开发背景，还是桌面/移动应用开发背景？我来自网络开发，状态图对我来说是一个新概念。我发现阅读 the canonical State Chart paper 非常有用David Harel('ware PDF!)。对于一篇学术论文来说，它的可读性令人惊讶，并列出了自 2010 年底以来大多数 SproutCore/Ember 世界一直在使用的基本状态图概念(即 Michael Cohen 在他写 Ki 时想到的。)