当控制器组件从磁带存储器请求某些数据,并且尚未加载该数据时,我们会触发ajax请求来获取数据.我们在发起请求时发送一个动作,在成功或失败时发送另一个动作.
这足以加载正确的数据,并在加载数据后更新存储.但是,我们在某些情况下需要知道某个ajax请求是挂起还是已完成 – 有时只是在一个或多个视图中显示微调器,或者有时在加载数据之前阻止其他操作.
在流量/反应应用程序中,是否存在人们用于此类行为的任何模式？这里有一些我考虑过的方法：
>拥有一个“请求状态”商店,该商店知道是否存在任何类型的待处理,已完成或失败的请求.这适用于简单的情况,例如“是否存在待处理的锻炼数据请求”,但如果我们想要更细化那么会变得复杂’是否有针对锻炼ID 123的待处理请求’
>让所有商店跟踪相关数据请求是否挂起,并将该状态数据作为商店API的一部分返回 – 即WorkoutStore.getWorkout将返回类似{status：’pending’,data：{}}的内容.这种方法的问题在于,似乎不应该将这种状态与域数据混合在一起,因为它实际上是一个单独的问题.此外,现在锻炼商店api的每个消费者都需要处理这种“状态响应”,而不仅仅是相关的域数据
>忽略请求状态 – 数据存在且控制器/视图对其起作用,或者数据不在那里且控制器/视图不对其起作用.更简单,但可能不足以达到我们的目的
解决方法
通常,#3很好,你的React组件只根据prop是否为null来决定是否显示一个微调器.
当您需要更好地跟踪请求时,您可能需要在请求本身级别进行此跟踪,或者您可能需要在正在更新的数据级别上进行此跟踪.这是两种不同的需求,需要类似但略有不同的方法.两种解决方案都使用客户端ID来跟踪请求,就像您在#1中所描述的那样.
如果调用操作创建者的组件需要知道请求的状态,则创建一个requestID并挂起this.state中的那个.稍后,该组件将检查通过props传递的请求集合,以查看requestID是否作为键存在.如果是这样,它可以读取那里的请求状态,并清除状态. RequestStore听起来像是存储和管理该状态的好地方.
但是,如果您需要知道特定记录级别的请求状态,管理此方法的一种方法是让您在商店中的记录同时保留clientID和更规范(服务器端)ID.这样,您可以将clientID创建为乐观更新的一部分,并且当响应从服务器返回时,您可以清除clientID.
我们在Facebook的一些项目中使用的另一个解决方案是创建一个动作队列作为商店的附件.动作队列是第二个存储区域.所有的getter都从商店本身和动作队列中的数据中抽取.因此,在响应从服务器返回之前,您的乐观更新实际上不会更新存储.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
