3

以重置密码为例。用户会看到一个表单，要求他们输入电子邮件。他们提交表单，以便在电子邮件中向他们发送重置链接。提交触发一个动作，该动作发出一个 POST/api/password/reset并返回成功或失败。

显然我想更新 UI，以便用户知道发生了什么。Flux 的方式是让动作调度一个常量，例如PASSWORD_RESET_SUCCESS，存储侦听调度程序，以便它们可以更改状态。组件侦听商店，以便在商店状态更改时更改 UI。

在密码重置的情况下，我真的看不出有一种明智的方式来让这个通过商店运行（这样做似乎很冗长）。唯一的状态变化似乎与该表单/组件直接相关。用户离开该页面后，无需保留任何内容。

  • 让组件直接监听调度程序是“flux-y”吗？
  • 商店是否有合理的设计，允许我处理此类不直接链接到应用程序中的模型的通用事件？

非常感谢！

（这与在https://github.com/mwillmott/techbikers上工作有关，以防有人感兴趣）

4

1 回答 1

0
  • 不，不是。Flux 的架构应该始终遵循相同的场景——组件调用 actionCreator，ActionCreator 将操作分派到商店，商店向所有订阅的组件发出更改。这就是 Flux 的工作原理，在此处进行了解释。
  • 我认为最好的方法是使用通用的 ResultStore，它只接受在操作中定义的键/值并将它们写入哈希。这样，您就可以使用一个名为 onResultWrite 或类似名称的处理程序。Flux Stores 从来都不是你的模型的直接表示——它们更像是你整个应用程序状态的表示。

Flux 架构显然对于简单的应用程序来说似乎过于严格和复杂——而且确实如此。但它并不是为简单的应用程序而设计的，它是为具有大量组件的复杂 UI 设计的——就像 get 一样复杂。这就是为什么 store、actions 和 components 需要尽可能地与它们自身分离的原因。

如果您认为您的应用程序非常简单，您总是可以采取捷径，例如将 changeState 回调作为参数直接传递给操作 - 但如果某些其他组件需要对 PASSWORD_RESET_SUCCESS 事件做出反应，那么您就有问题了. 但是，当它发生时，您总是可以考虑它。项目架构总是关于权衡、灵活性、开发速度和性能。

开发人员最重要的技能是了解这种权衡、它们的价值并知道在哪里制造它们——在哪里不做。

祝你好运！

于 2015-06-24T14:27:54.447 回答