为什么使用redux-thunk或者redux-saga来获取？

我一直在阅读，我应该使用redux-thunk或者redux-saga来处理副作用。为什么不能简单地用行动创造者一样，派遣多个动作：为什么使用redux-thunk或者redux-saga来获取？

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）。所以我想一定有一些我不知道的麻烦。

来源

2016-12-11 sylvain

你可以这么做。当你用手动创建每个动作创建者的包装（就像你在45-47行上做的那样）时，你放弃了并且采取了一些重要的步骤。 – zerkms

所以这是唯一的好处？避免为这类任务创建几个动作？ – sylvain

如果你检查redux-thunk代码，你会发现它导出的函数只有4（4）行代码https://github.com/gaearon/redux-thunk/blob/master/src/index.js – zerkms

你的代码是类似于咚呢。

按照redux文档，操作应该是纯粹的。并且他们应该始终为相同的输入参数返回相同的值。通过使用fetch，您允许操作返回非具体值，而非来自服务器的值，并且平均操作响应可能随时间而变化。

这就是所谓的副作用。这是默认情况下不应该进行重复动作的事情。

但是为什么？

是的，你可以在你的动作中键入它，在小应用程序中它并不重要。

在较大的应用有使用redux-saga的好处：

行为是可以预见的，他们只是返回的有效载荷像

{ 
    type: 'FETCH_POSTS', 
    params: { 
    category: 'programming' 
    } 
}

，然后你建立中间件将采取所有数据的操作需要执行真实API的请求

个可能的优点：

清洁的代码库（但可能是开销较小的应用程序）
分离与所有需要的信息“虚拟”的行动来执行请求和实际的API中间件
请求参数可见直接在终极版开发工具
可以容易地debounce，throttle取这可能与真正棘手终极版 - 咚
可能easil Y组合起来的动作（等待另一个事件/读取，一连串的事件）
可以停止正在运行的任务

从个人的经验，对我们已经开始与redux-thunk一个项目（较大的代码库），但后来我们需要集成更多高级功能，例如油门，以及一些动作之间的依赖关系。所以我们将所有内容重写为redux-saga，它对我们来说效果很好。

来源

2017-05-29 17:20:24 Jurosh

你是在这里复制redux-thunk。纯粹的redux动作创建者应该返回一个要分派的动作对象，而不是派发一个动作本身（参见redux doc on action creator）。

为了更好地理解为什么你的技术方法终极版，thunk的复制，看this post从它的作者

来源

2016-12-12 11:56:28

为什么使用redux-thunk或者redux-saga来获取？

回答

相关问题