saga使用后体验
优点一,分离了action和effect,变得更纯粹
感觉这不是他的核心重点,因为即使分离了,也没法复用
action为异步请求,在saga中只不过是,将thunk的异步请求分离到了saga中
然后再put(action)等价于thunk 中的dispatch
真正优点
- takeLatest处理重复点击的问题,一定业务条件下不用写debounce
takeLatest,在上个程序没有运行完的时候,再次运行会取消上一个任务
- reace,超时自动取消
function* controlSaga (action) {
const task = yield fork(getDataSaga, action); // 运行getDataSaga这个任务
yield race([ // 利用rece谁先来用谁的原则,完美解决 超时自动取消与手动取消的 的问题
take('CANCEL_REQUEST'), // 到这步时就阻塞住了,直到发出type为'CANCEL_REQUEST'的action,才会继续往下
call(delay, 1000) // 控制时间
]);
yield cancel(task); // 取消任务,取消后,cancelled() 会返回true,否则返回false
}
官网案例
import { race, call, put } from 'redux-saga/effects'
import { delay } from 'redux-saga'
function* fetchPostsWithTimeout() {
const {posts, timeout} = yield race({
posts: call(fetchApi, '/posts'),
timeout: call(delay, 1000)
})
if (posts)
put({type: 'POSTS_RECEIVED', posts})
else
put({type: 'TIMEOUT_ERROR'})
}
这样每个Api请求直观拿数据,不用担心超时要怎么传递参数的问题,对于后端来说,可以不用去看封装的http请求函数