[译]在 Redux 中使用 AJAX 轮询(二):Saga 篇

2017-12-30 11:20:18来源:https://juejin.im/post/5a43b80df265da43176a6e4e作者:稀土掘金人点击

分享

原文地址:AJAX POLLING IN REDUX PART 2: SAGAS
原文作者:Josh M
译文出自:掘金翻译计划
本文永久链接:github.com/xitu/gold-m…
译者:刘嘉一
校对者:yoyoyohamapi
,FateZeros


不久之前我写了一篇关于在 React 中使用 AJAX 轮询的短文,内容可以概括为如何发起和控制周期性 AJAX 请求。文中我证明了通过使用组件生命周期方法,原生 React 和 Redux 在技术上就足以解决 AJAX 轮询的控制问题。随着时间推移,在使用中我发现这个方法需要开发者非常细心地筛选和管理componentWillReceiveProps
中传入的 props 。最终,我的目标变成了尽可能地清除组件中的异步逻辑。



在 Redux 生态中,已有不少管理副作用(side effect)的类库,从最基础的redux-thunk
,到受 Elm 熏陶的redux-loop
,最后还有使用 Generator 函数强力驱动的redux-saga



理想情况下,我喜欢把所有的异步请求都放置到一个 API 中间件中,这种用法可以参考 Redux 官方实例real-world example
。若使用 thunk 会使我的 Action 创建函数被异步逻辑所污染,所以redux-thunk
已然出局。使用redux-loop
则会与我的中间件相冲突,作为 store 的一个 enhancer 它却修改了 store 的 signature,进而导致其下游的所有中间件都需要调整。所以综上我决定探索redux-saga
,它本质上提供给我的是在应用后台执行任务的能力。使用redux-saga
可以保证我利用中间件集中控制异步逻辑的用法不变,同时通过设定各类不同的观察者(watcher)来触发副作用。那么如何使用 redux-sage 处理 AJAX 轮询呢?


// 延时副作用的工具函数
function delay(millis) {
const promise = new Promise(resolve => {
setTimeout(() => resolve(true), millis)
});
return promise;
}
// 每隔 20 秒获取一次数据
function* pollData() {
try {
yield call(delay, 20000);
yield put(dataFetch());
} catch (error) {
// 取消异常 -- 如果你愿意也可以捕获
return;
}
}
// 等待上一次数据请求返回成功后,发起下一轮轮询
// 如果用户登出,则取消本次未完成的轮询
function* watchPollData() {
while (true) {
yield take(DATA_FETCH_SUCCESS);
yield race([
call(pollData),
take(USER_LOGOUT)
]);
}
}
// 让各类任务在后台并行运行
export default function* root() {
yield [
fork(watchPollData)
// 此处可包含其他观察者
];
}


这种以 sagas 存在的轮询逻辑让开发者免于处理组件中潜在的复杂生命周期。我在 race 条件中添加了USER_LOGOUT
Action,这样可以代劳之前componentWillUnmount
中clearTimeout
的工作。当发送 logout Action 后,运行中的pollData
saga 就可以被很好地中断执行。


其余涉及到的逻辑如下:



dataFetch
-- 它是一个 Action 创建函数,产生的 Action 会被 API 中间件拦截并处理。在中间件中会发起真正的 API 请求,并根据请求结果发出一系列后续 Action。



watchPollData
-- 它是一个随应用启动并一直运行的 saga。启动后它会阻塞 saga 执行并监听DATA_FETCH_SUCCESS
Action 的发出。一旦监听到相应的 Action 被发出,它就解除阻塞继续执行后续的pollData
saga。



pollData
-- 先阻塞 Generator 函数的执行,20秒后再调用dataFetch
并 dispatchdataFetch
产生的 Action。



此处用到的take
、put
、race
、call
和fork
作用符,都可以在redux-saga documentation
中找到。


你可以将本文的新方法与前一篇文章中在组件内做控制的方法作比较,使用 saga 后更利于预测和集中管理我的副作用。需要注意的是并不是所有的浏览器都支持 Generator 函数,如果你使用了 ES2015 和 Babel,那么它们已经提供了 Generator 函数的浏览器 polyfill 兼容支持。



现在所有的数据容器(组件)只需在挂载的时候简单地调用一次dataFetch()
即可,之后我们的 saga 就会自动接管所有的轮询工作。非常简而美吧。



掘金翻译计划
是一个翻译优质互联网技术文章的社区,文章来源为掘金 上的英文分享文章。内容覆盖Android
、iOS
、前端
、后端
、区块链
、产品
、设计
、人工智能
等领域,想要查看更多优质译文请持续关注掘金翻译计划
、官方微博、知乎专栏


最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台