我一直在读,我应该使用redux-thunk或redux-saga来处理副作用. 为什么不简单地使用这样的动作创建者来发送多个动作: function loadProductActionCreator(dispatch) { dispatch({ type: 'load_product', }) fetch('
为什么不简单地使用这样的动作创建者来发送多个动作:
function loadProductActionCreator(dispatch) { dispatch({ type: 'load_product', }) fetch('api/product').then( function (r) { return r.json(); } ) .then(function (res) { dispatch({ type: 'loaded_product', data: res }) }) }
我试过了,它起作用了(complete code).所以我想一定有一些我不知道的不便之处.
你的代码类似于thunk的代码.根据redux docs,行动应该是纯粹的.并且它们应始终为相同的输入参数返回相同的值.通过使用fetch,您允许操作返回非特定值,而不是返回服务器的值,这意味着操作响应可能会随时间而变化.
这被称为副作用.并且这是默认情况下不应该在redux操作中的内容.
但为什么?
是的,你可以像你一样在里面输入它,在小应用程序中它并不重要.
在更大的应用程序中,使用redux-saga有好处:
>动作是可预测的,它们只返回有效载荷
{ type: 'FETCH_POSTS', params: { category: 'programming' } }
>然后构建中间件,该中间件将对执行实际API请求所需的所有数据执行操作
可能的优点:
>清洁代码库(但可能是较小应用程序的开销)
>使用所有必需信息分离“虚拟”操作以执行请求和实际API中间件
>请求参数可直接在redux dev工具中查看
>可以轻松去抖动,限制使用redux-thunk可能非常棘手的提取
>可以轻松组合动作(等待另一个事件/获取,链事件)
>可以停止运行任务
从个人经验来看,在一个项目(更大的代码库)上我们已经开始使用redux-thunk,但后来我们需要集成更高级的功能,比如节流,以及操作之间的一些依赖关系.因此我们将所有内容重写为redux-saga并且它对我们来说效果很好.