在UI

Question

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

显然我想更新UI，以便用户知道发生了什么。 Flux方式是让动作调度一个常数，例如PASSWORD_RESET_SUCCESS和商店听取调度员的意见，以便他们可以改变状态。组件会侦听商店，以便在商店状态发生变化时更改UI。

在密码重置的情况下，我无法真正看到一种明智的方式让它在商店中运行（这似乎很冗长）。唯一的状态变化似乎与该形式/组件直接相关。一旦用户离开该页面，就不需要保留任何内容。

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

非常感谢！

（这与https://github.com/mwillmott/techbikers的工作有关，如果有人感兴趣的话）

Answer 1

• 不，不是。 Flux的体系结构应始终遵循相同的方案 - 组件调用actionCreator，ActionCreator将操作分派给存储，存储发出更改到所有预订组件。这就是Flux的工作原理，解释here。
• 我认为最好的方法是使用通用的ResultStore，它只接受动作中定义的键/值并将它们写入散列。这样你就可以使用一个名为onResultWrite的处理程序或类似的东西。 Flux Stores从未打算直接代表您的模型 - 它们更能代表您的整个应用程序状态。

对于简单的应用程序来说，Flux架构显然看起来过于严格和复杂 - 而且确实如此。但它并非专为简单的应用程序而设计，它专为具有大量组件的复杂UI而设计 - 与get一样复杂。这就是为什么商店，行动和组件需要尽可能地与自己分开。

如果您认为您的应用程序非常简单，您可以随时使用快捷方式，例如将changeState回调作为参数直接传递给操作 - 但如果某个其他组件需要对PASSWORD_RESET_SUCCESS事件做出反应，那么您已经有了你自己是个问题。尽管如此，你总是可以考虑它。项目架构始终是权衡取舍，灵活性与开发速度与性能的关系。

开发人员最重要的技能是了解这种权衡，他们的价值并知道在哪里制作 - 以及不在哪里。

祝你好运！