我正在使用MartyJS构建一个Flux应用程序(它非常接近"vanilla"Flux并使用相同的底层调度程序).它包含具有固有依赖关系的商店.例如,a UserStore跟踪当前用户,以及InstanceStore跟踪当前用户拥有的数据实例.实例数据是异步从API获取的.
问题是如何处理InstanceStore用户更改时的状态.
我开始相信(例如,阅读@fisherwebdev在SO上的答案),最适合在动作创建者函数中发出AJAX请求,并在动作中产生AJAX"成功"结果,从而导致商店发生变化.
因此,为了获取用户(即登录),我正在动作创建者函数中进行AJAX调用,当它结算时,我RECEIVE_USER将作为有效负载向用户发送动作.在UserStore这个监听并相应地更新其状态.
但是,InstanceStore如果用户更改,我还需要重新获取所有数据.
选项1:我可以RECEIVE_USER在其中监听InstanceStore,如果是新用户,则触发AJAX请求,该请求又创建另一个动作,从而导致InstanceStore更新.这个问题就是它感觉像是级联动作,虽然技术上它是异步的,所以调度员可能会允许它.
选项2:另一种方式是InstanceStore听取发出的变化事件UserStore并进行请求 - 动作舞蹈,但这也是错误的.
选项3:第三种方式是动作创建者编排两个AJAX调用并分别发送这两个动作.但是,现在动作创建者必须知道很多关于商店如何相互关联的信息.
在Flux应用程序中应该在哪里进行ajax请求？让我觉得选项1是正确的,但Flux文档也暗示商店触发行动并不好.
从概念上讲，选项 1 对我来说似乎是最佳选择。有 2 个单独的 API 调用，因此您有 2 组事件。
少量代码中包含大量事件，但 Flux 始终依赖于使用简单、标准的 Action->Store->View 方法。一旦你做了一些聪明的事情（比如选项 2），你就改变了这一点。如果其他开发人员不能再安全地假设任何操作流程与其他操作流程完全相同，那么您就失去了 Flux 的巨大优势。
但这并不是代码中最短的方法。MartyJS 看起来至少比 Facebook 自己的 Flux 库更整洁一些！
不同的选择；如果登录必须始终刷新 InstanceStore，为什么不让登录 API 调用也包含所有 InstanceStore 数据呢？
（更进一步；为什么有 2 个独立的存储？它们似乎都耦合得非常紧密，并且没有理由您不能在不重新调用登录的情况下仍然调用 InstanceStore API）
| 归档时间： |
|
| 查看次数： |
765 次 |
| 最近记录： |