在我的应用中，我正在使用React和Reflux，并对我的数据进行了分层设置。我正试图将我的应用程序的元素分成不同的商店，以便能够正确地挂钩事件并分离问题。
我有以下数据流：
Workspaces -> Placeholders -> Elements
在此方案中，创建工作空间时，必须依次使用对新创建的工作空间的引用（ID）创建默认占位符。这同样适用于占位符与元素关系。
Reflux方式似乎表明PlaceholderStore会侦听来自WorkspaceStore的触发器，并将新创建的ID添加到this.trigger()。
Reflux只允许从商店触发单个事件;从而防止外部组件能够辨别create或update个动作。这意味着如果商店中的一个触发器将ID发送为argument[0]，则后续触发器应该执行相同的操作（以保持一致）。对于寻找多个工作区更新的组件（例如重新排序/批量更新），这是一个问题。
我曾想过添加StoreActions的概念;只有商店可以创建的操作，然后其他商店才会收听（有效地从商店中丢弃原始触发器）。通过这些组件/商店可以监听特定事件，并且可以毫无顾虑地定制传递给所述事件的参数。这似乎是一种错误的方式去滥用Reflux事件系统。
我应该尝试分解相关数据吗？是否有更好的方法来构建数据？
我已经阅读了关于聚合商店的信息，但没有看到任何解剖的实现。这些是通过将来自多个商店的数据放在一起提供解决方案吗？如果是，那么负责创建React组件可以收听的事件的是什么？
非常感谢任何人提供的任何帮助/见解！
答案 0 :(得分：12)
Yes, it is perfectly reasonable to call actions from a store。我将操作视为数据流的启动器，我将异常流视为单独的流。
一个很好的例子是一个CRUD商店，它也处理AJAX调用（CRUD与服务器端的数据）。一旦数据更新，商店就会触发更改事件。但是，如果AJAX调用失败，它应该为此启动数据流，以便其他存储和组件可以监听它们。从头到尾，这些错误符合Toast / notification组件和Analytics错误日志记录的利益，例如GA Exceptions。
AJAX示例也可以通过操作中的preEmit挂钩实现，并且有several examples among the github issues discussion。甚至还有"async actions" helper。
根据设计，商店只发出变更事件。如果要发出其他类型的事件，它基本上意味着您正在启动应该使用操作的新数据流。