Flux架构在示例聊天应用中存在误解

Question

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

但是，在示例应用中，Action Creators（ChatMesssageActionCreator）和Stores（MessageStore）之间以及Stores之间存在依赖关系（{{3 }}，MessageStore）和Web API Utils（ThreadStore），这似乎违反了单向数据流规则：

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

更新

我发现ChatMessageUtils并不属于Web API Utils，因此商店中的两个箭头不应该指向那里，因此可能它们没有问题。 然而，ActionCreator和商店之间的联系似乎仍然很奇怪。

Answer 1

该示例有点强制，它的创建目的是试图显示waitFor（）的工作原理。该示例的WebAPI方面非常不完整，应该进行修改。

但是，即使MessageStore.getCreatedMessageData(text)将值传递给商店，它仍然是一个吸气剂。它没有在商店中设置数据。它真的被用作实用程序方法，一个好的修订版（拉取请求？）就是将该方法移动到Utils模块。

为了改进现实世界的例子，你可能会做一些事情：

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

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

所有这些都说，是的，这个例子需要修改。