12

大纲

在我的应用程序中,我使用ReactReflux,并且对我的数据进行了分层设置。我正在尝试将我的应用程序的元素分解为单独的商店,以便能够正确挂钩事件并分离关注点。

我有以下数据流:

Workspaces -> Placeholders -> Elements

在这种情况下,创建工作空间时,必须依次创建默认占位符,并使用对新创建的工作空间的引用 (ID)。这同样适用于占位符与元素的关系。

关键

Reflux 方式似乎建议 PlaceholderStore 监听来自 WorkspaceStore 的触发器,将新创建的 ID 添加到this.trigger().

Reflux 只允许从商店触发单个事件;从而防止外部组件能够识别createupdate采取行动。这意味着如果商店中的一个触发器将 ID 发送为argument[0],则后续触发器应该执行相同的操作(以保持一致)。对于寻找多个工作区的更新(例如重新排序/批量更新)的组件来说,这是一个问题。

不受欢迎的解决方案

我曾想过添加一个概念StoreActions;只有商店可以创建的操作,然后其他商店会监听(有效地从商店丢弃原始触发器)。有了这个组件/商店可以监听特定的事件,传递给所述事件的参数可以被定制而无需担心。这似乎是一种错误的方式,也是对 Reflux 事件系统的滥用。

帮助

我应该尝试分解相关数据吗?有没有更好的方法来构建数据?

我已经阅读了有关聚合存储的信息,但没有看到任何要剖析的实现。这些是否提供了一个解决方案,将来自多个商店的数据整合在一起,如果是,那么是什么负责创建 React 组件可以监听的事件?

非常感谢任何人都可以提供的任何帮助/见解!

4

1 回答 1

12

是的,从 store 调用 action 是完全合理的。我将动作视为数据流的发起者,并将异常流视为单独的流。

一个很好的例子是一个 CRUD 存储,它也处理 AJAX 调用(在服务器端对数据进行 CRUD)。商店将在数据更新后立即触发更改事件。但是,如果 AJAX 调用失败,它应该改为为此启动数据流,以便其他商店和组件可以监听这些。在我看来,此类错误符合 toast/notification 组件和 Analytics 错误日志记录,例如GA Exceptions

AJAX 示例也可以通过动作中的钩子实现,在 github 问题讨论中preEmit有几个示例。甚至还有这个“异步操作”助手

按照设计,商店只发出一个更改事件。如果您想发出其他类型的事件,这基本上意味着您正在开始新的数据流,您应该使用操作来代替。

于 2014-12-18T08:14:58.163 回答