JonyYu
JonyYu
谢谢表扬哈，去了一家小公司哈
是的，确实不需要用saga
> ### 你好，使用saga我有一个问题： > > 关于： UI 中获取异步请求结果后，执行后续 UI 操作 > > 我在UI中调用 action 触发异步请求，例子中成功后我可以修改 store。 > 但是我想在 UI 中异步请求结束后能够 alert('请求结束') > 这里怎么写比较好？ 首先先接受一个action，通过redux-saga中的take，然后通过redux-saga中的call 方法调用一个请求函数 yield call( ...fetchURL,params) , yield会等待call方法返回结果后再往下执行，调用yield...
> 想请教一下，为什么实例代码中的 generator 函数里面要写 while(true) 来包裹逻辑？ > 例如： > > ``` > function * watchUsername(){ > while(true){ > const action= yield take('CHANGE_USERNAME'); > yield put({type:'change_username', > value:action.value}); > } >...
> 有些明白了，非常感谢帮助！ 不客气～
> > 2.redux-saga写一个hellosaga > > 跟redux-thunk,redux-saga是控制执行的generator > > 这儿应该是 `跟 redux-thunk 不同的是,` 吧。 > > 顺便，感谢 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);...
> @forthealllight 感谢解答，很有帮助~ 还有一个补充，takeEvery虽然是一个顶层API，但是他是action发起时，被push到任务执行器然后执行的。而用底层API take的好处，是去pull新任务，然后执行。 两者的却别就是使用take可以实现更复杂的控制逻辑，比如使用takeEvery无法结束监听，而底层的take就很方便。 简单来说，可以用一句话概括：底层的API，实现细节更加可控哦～ 不用谢