Flux中的AJAX：当依赖状态发生变化时刷新存储
|
我正在使用MartyJS构建一个Flux应用程序(它非常接近“vanilla”Flux并使用相同的底层调度程序).它包含具有固有依赖关系的商店.例如,UserStore跟踪当前用户,InstanceStore跟踪当前用户拥有的数据实例.实例数据是异步从API获取的.
问题是当用户更改时如何处理InstanceStore的状态. 我开始相信(例如,阅读@fisherwebdev关于SO的答案),最适合在动作创建者函数中发出AJAX请求,并在动作中产生AJAX“成功”结果,从而导致商店发生变化. 因此,为了获取用户(即登录),我在动作创建器函数中进行AJAX调用,当它结算时,我将调度RECEIVE_USER操作作为有效负载. UserStore会侦听它并相应地更新其状态. 但是,如果用户更改,我还需要重新获取InstanceStore中的所有数据. 选项1：我可以在InstanceStore中侦听RECEIVE_USER,如果它是新用户,则触发AJAX请求,该请求又创建另一个操作,从而导致InstanceStore更新.这个问题就是它感觉像是级联动作,虽然技术上它是异步的,所以调度员可能会允许它. 选项2：另一种方法是InstanceStore监听UserStore发出的更改事件并执行请求 – 动作舞蹈,但这也是错误的. 选项3：第三种方式是动作创建者编排两个AJAX调用并分别发送这两个动作.但是,现在动作创建者必须知道很多关于商店如何相互关联的信息. Where should ajax request be made in Flux app?中的一个答案让我觉得选项1是正确的,但Flux文档也暗示存储触发操作并不好. 解决方法
像选项3这样的东西对我来说似乎是最干净的解决方案,其次是选项1.我的推理：
选项2偏离了处理商店之间依赖关系的预期方式(waitfor),您必须在每个更改事件之后检查以确定哪些相关以及哪些可以忽略,或者开始使用多个事件类型;它可能变得相当混乱. 我认为备选方案1是可行的;如您链接的帖子中的Bill Fisher remarked,可以从商店内进行API调用,只要通过调用新操作处理结果数据即可.但是OK并不一定意味着理想,如果您可以在一个地方(即ActionCreators)收集所有API调用和操作启动,那么您可能会更好地分离关注点并减少级联.这与选项3一致.
在我看来,动作创建者不需要知道商店正在做什么.它只需要登录用户,然后获取与用户关联的数据.无论这是通过一个或两个API调用完成的,这些在逻辑上非常紧密地耦合并且在一个动作创建者的范围内有意义.一旦用户登录并获得了数据,您就可以触发两个操作(例如LOGGED_IN,GOT_USER_DATA)或甚至只包含一个包含两者所需的所有数据的操作.无论哪种方式,这些操作都只是回应API调用所做的事情,并且由商店来决定如何处理它. 我建议使用单个操作来更新两个存储,因为这似乎是waitfor的一个完美用例：当一个操作在两个存储中触发处理程序时,您可以指示InstanceStore在InstanceStore的处理程序执行之前等待UserStore的处理程序完成.它看起来像这样： UserStore.dispatchToken = AppDispatcher.register(function(payload) {
switch (payload.actionType) {
case Constants.GOT_USER_DATA:
...(handle UserStore response)...
break;
...
}
});
...
InstanceStore.dispatchToken = AppDispatcher.register(function(payload) {
switch (payload.actionType) {
case Constants.GOT_USER_DATA:
AppDispatcher.waitFor([UserStore.dispatchToken]);
...(handle InstanceStore response)...
break;
...
}
});
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |