reactjs - 为什么使用 redux-thunk 或 redux-saga 进行获取？

Question

我一直读到我应该使用 redux-thunk 或 redux-saga 来处理副作用。 为什么不简单地使用像这样的 Action 创建者来调度多个 Action :

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 )。所以我想一定有一些我没有意识到的不便。

Answer 1

您的代码与 thunk 的做法类似。

根据 redux 文档，操作应该是纯粹的。并且它们应该始终为相同的输入参数返回相同的值。通过使用fetch，您允许操作返回非特定值，而是返回来自服务器的值，这意味着操作响应可能会随时间而变化。

这就是所谓的副作用。默认情况下，这是不应该出现在 redux 操作中的内容。

但是为什么呢？

是的，您可以像以前一样在操作中输入它，在小型应用程序中这并不重要。

在较大的应用程序中，使用redux-saga有以下好处:

• 操作是可预测的，它们只是返回有效负载，例如

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

• 然后您构建中间件，该中间件将使用执行对真实 API 的请求所需的所有数据执行操作

可能的优势:

• 更干净的代码库(但对于较小的应用程序可能会产生开销)
• 将“虚拟”操作与执行请求所需的所有信息与实际 API 中间件分开
• 请求参数在 redux 开发工具中直接可见
• 可以轻松地debounce、throttle获取，这对于redux-thunk来说可能非常棘手
• 可以轻松组合操作(等待另一个事件/获取、链式事件)
• 可以停止正在运行的任务

根据个人经验，在一个项目(较大的代码库)中，我们一开始使用的是 redux-thunk，但后来我们需要集成更高级的功能，例如节流以及操作之间的一些依赖关系。因此，我们将所有内容重写为 redux-saga，它对我们来说效果很好。