彻彻底底教会你使用Redux-saga(包含样例代码) about blog HOT 29 OPEN

写的很清晰易懂👍

有一个小问题， 为什么要用saga 来 watch用户输入账户和密码呢？这个过程没有异步操作， 可以直接被reducer捕捉到。

from blog.

写的很详细，女生就是细腻一点
冒昧问一下，楼主最后去了哪家公司呢？

from blog.

想请教一下，为什么实例代码中的 generator 函数里面要写 while(true) 来包裹逻辑？
例如：

function * watchUsername(){
  while(true){
    const action= yield take('CHANGE_USERNAME');
    yield put({type:'change_username',
    value:action.value});
  }
}

您好，看到你的问题。第一时间来回答你，因为type = ‘CHANGE_USERNAME’ 动作不可能只发生一次。
我这里的业务要求，只要发生了该动作就会执行相应的逻辑。whilte(true) 的意思是一直监听，被监听的动作不止一次的发生。

当然，你如果只需要监听一次动作， 那么就不需要while循环。

～

from blog.

👍

from blog.

小姐姐你好，请问下实际业务中，saga.js这个文件怎么拆分呢，不可能不同业务几十个函数全放一个文件

我是按页面拆分的，一个页面对应一个saga文件，然后在根目录require到一起的哦，具体可以看我的这篇文章#41

from blog.

写的很不错

from blog.

谢谢哈

from blog.

谢谢表扬哈，去了一家小公司哈

from blog.

是的，确实不需要用saga

from blog.

你好，使用saga我有一个问题：

关于： UI 中获取异步请求结果后，执行后续 UI 操作

我在UI中调用 action 触发异步请求，例子中成功后我可以修改 store。
但是我想在 UI 中异步请求结束后能够 alert('请求结束')
这里怎么写比较好？

from blog.

你好，使用saga我有一个问题：

关于： UI 中获取异步请求结果后，执行后续 UI 操作

我在UI中调用 action 触发异步请求，例子中成功后我可以修改 store。
但是我想在 UI 中异步请求结束后能够 alert('请求结束')
这里怎么写比较好？

首先先接受一个action，通过redux-saga中的take，然后通过redux-saga中的call 方法调用一个请求函数 yield call( ...fetchURL,params) , yield会等待call方法返回结果后再往下执行，调用yield call请求后，你就可以alert('请求结束') ， 如果不想用window.alert(), 你可以在store中保存alert是否显示的变量，在yield call后，改变这个变量的值，使得自定义的alert弹窗显示

from blog.

@forthealllight
嗯好的，谢谢你的回答
其实我想实现的是类似 dva 一样的操作（像下面的操作），这个我再去看下吧
https://github.com/zuiidea/antd-admin/blob/master/src/pages/user/index.js#L38-L46

from blog.

想请教一下，为什么实例代码中的 generator 函数里面要写 while(true) 来包裹逻辑？
例如：

function * watchUsername(){
  while(true){
    const action= yield take('CHANGE_USERNAME');
    yield put({type:'change_username',
    value:action.value});
  }
}

from blog.

有些明白了，非常感谢帮助！

from blog.

有些明白了，非常感谢帮助！

不客气～

from blog.

2.redux-saga写一个hellosaga
跟redux-thunk,redux-saga是控制执行的generator

这儿应该是 跟 redux-thunk 不同的是, 吧。

顺便，感谢 blog 的帮助-.-

from blog.

有几点疑问想请教一下：

1. 把请求全部放在saga里面，如果UI-components在请求成功后有其他操作如何处理？比如要修改页面某个图标颜色。
2. 文中所诉模式是不是把数据全部存在了store，而弃用了state，在大型单页项目中会不会有性能问题。
3. while（true）写法是不是等同于takeEvery？

from blog.

2.redux-saga写一个hellosaga
跟redux-thunk,redux-saga是控制执行的generator

这儿应该是 跟 redux-thunk 不同的是, 吧。

顺便，感谢 blog 的帮助-.-

感谢指正，已经修改

from blog.

有几点疑问想请教一下：

1. 把请求全部放在saga里面，如果UI-components在请求成功后有其他操作如何处理？比如要修改页面某个图标颜色。
2. 文中所诉模式是不是把数据全部存在了store，而弃用了state，在大型单页项目中会不会有性能问题。
3. while（true）写法是不是等同于takeEvery？

1、UI在请求后如何处理，一般是这样子，在saga中请求，请求完成后更新store中的state，而UI-components从store中取新的state，以props的形式传递，从而更新整个视图。这里跟你用redux-thunk一样的，仅仅是一个异步的中间件。本质还是redux做状态管理。

2、我知道你说所的可能是无效render。在设计redux树的时候，可以选择完全弃用局部的state，将所有状态保存在store中，这种情况不会有性能问题，可以通过SCU来控制渲染实现你所说的优化。当然，有些也不需要完全弃用局部state，你这个问题本质是一个如何设计redux状态树的问题。

总结： 1、2 两个问题其实本质跟redux-saga无关，是redux的问题

3、可以理解成

whille(true){
const action = yield take(someaction)
}

等价于

const action yield takeEvery(someaction);

本质上takeEvery是根据take来实现的一个上层的API。

最后，希望能对你有所帮助～

from blog.

@forthealllight 感谢解答，很有帮助~

from blog.

@forthealllight 感谢解答，很有帮助~

还有一个补充，takeEvery虽然是一个顶层API，但是他是action发起时，被push到任务执行器然后执行的。而用底层API take的好处，是去pull新任务，然后执行。

两者的却别就是使用take可以实现更复杂的控制逻辑，比如使用takeEvery无法结束监听，而底层的take就很方便。

简单来说，可以用一句话概括：底层的API，实现细节更加可控哦～

不用谢

from blog.

你好，有个问题请教下。看了下你另一个仓库saga-example中的例子，因为是只有登录和获取列表的异步，所以saga的相关代码是放在src/saga/index.js中。
如果是较复杂的应用，saga如何组织呢？是否能够和combineReducers一样将不同页面的reducers合并到一起，根据不同页面就近维护自己的saga，然后最终在store/index.js中import各个页面自己的saga，统一到sagaMiddleware.run(rootSaga)中。

from blog.

你好，有个问题请教下。看了下你另一个仓库saga-example中的例子，因为是只有登录和获取列表的异步，所以saga的相关代码是放在src/saga/index.js中。
如果是较复杂的应用，saga如何组织呢？是否能够和combineReducers一样将不同页面的reducers合并到一起，根据不同页面就近维护自己的saga，然后最终在store/index.js中import各个页面自己的saga，统一到sagaMiddleware.run(rootSaga)中。

当然可以，这个就是我所说的redux-dark模式。你可以参考我的这篇文章：#41

from blog.

@forthealllight 谢谢。我尝试下你所说的redux-dark。

from blog.

小姐姐你好，请问下实际业务中，saga.js这个文件怎么拆分呢，不可能不同业务几十个函数全放一个文件

from blog.

小姐姐你好，请问下实际业务中，saga.js这个文件怎么拆分呢，不可能不同业务几十个函数全放一个文件

我是按页面拆分的，一个页面对应一个saga文件，然后在根目录require到一起的哦，具体可以看我的这篇文章#41

那这样的话，reducer的状态会不会被拆的太散了，比如 2个页面可能复用一个reducer。

from blog.

小姐姐你好，请问下实际业务中，saga.js这个文件怎么拆分呢，不可能不同业务几十个函数全放一个文件

我是按页面拆分的，一个页面对应一个saga文件，然后在根目录require到一起的哦，具体可以看我的这篇文章#41

那这样的话，reducer的状态会不会被拆的太散了，比如 2个页面可能复用一个reducer。

保持一个页面一个reducer的拆分

from blog.

感谢小姐姐，学习了

from blog.

目前硬要我挑个毛病的话，redux-thunk的缺点下面的单词少了个t

from blog.