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