示例聊天应用程序中的 Flux 架构误解

Question

我正在尝试理解Flux example chat app。作者提到了这种单向数据流：

但是，在示例应用程序中，Action Creators (ChatMesssageActionCreator) 和 Stores (MessageStore) 之间以及 Stores (MessageStore, ThreadStore) 和 Web API Utils ( ChatMessageUtils)，这似乎违反了单向数据流规则：

是否建议遵循给定的示例，还是应该设计一个更好的模式？

更新

我发现 ChatMessageUtils 不属于 Web API Utils，因此 store 中的两个箭头不应该指向那里，因此也许它们没问题。 但是 ActionCreators 和 Store 之间的联系似乎仍然很奇怪。

Answer 1

这个例子有点勉强，创建它的目的是为了展示 waitFor() 的工作原理。该示例的 WebAPI 方面相当不成熟，确实应该修改。

然而，即使MessageStore.getCreatedMessageData(text) 将值传递给存储，它仍然是一个getter。它不是在商店中设置数据。它确实被用作实用方法，一个好的修订（拉取请求？）是将该方法移动到 Utils 模块。

要改进现实世界的示例，您可以做几件事：

• 从商店而不是从 ActionCreators 调用 WebAPIUtils。这很好，只要响应调用另一个 ActionCreator，而不是通过直接在存储中设置新数据来处理。重要的是让新数据起源 一个动作。数据如何进入系统比数据如何退出系统更重要。

• 或者，您可能希望消息具有单独的客户端 ID 和服务器端 ID。这样做可能没有什么好处，比如管理乐观的渲染。在这种情况下，您可能希望在 Utils 模块中生成客户端 id，并将该 id 与文本一起传递给调度的操作和 WebAPIUtils。

说了这么多，是的，这个例子需要修改。