使用redux-thunk和直接调用dispatch（）有什么区别

Question

我正处于理解redux状态管理的学习阶段，并且仍在努力谈判令人困惑的样板代码和中间件丛林，其中大部分我都认为它是“良药”。 所以我希望你能在这个或许基本的问题上忍受我。

我知道redux-thunk允许动作创建者异步进行并在随后的时间发送一个常规动作。 例如，我可以在actions.js定义thunk动作创建器：

export function startTracking() {
  return (dispatch => {
     someAsyncFunction().then(result => dispatch({
       type: types.SET_TRACKING,
       location: result
     }))
  })
}

并从React组件中调用它，如下所示：

onPress={() => this.props.dispatch(actions.startTracking())}

我的问题是 ，上面的代码有什么优势可以简单地从异步回调中调度一个动作？

import { store } from '../setupRedux'
...

export function startTracking() {
 someAsyncFunction().then(result => {
   store.dispatch({
     type: types.SET_TRACKING,
     location: result
   })
 })
}

我会在我的组件中调用它

onPress={() => actions.startTracking()}

甚至

onPress={actions.startTracking}

通过导入直接访问store是否有任何问题，正如我在第二个例子中所做的那样？

Answer 1

这样做没有错。 从redux-thunk页面 ：

如果你不确定是否需要它，你可能不会。

redux的创建者解释了在这里使用它的优势：

这看起来更简单，但我们不建议采用这种方法。 我们不喜欢它的主要原因是因为它迫使商店成为单身人士。 这使得实现服务器呈现非常困难。 在服务器上，您将希望每个请求都有自己的存储，以便不同的用户获得不同的预加载数据。

基本上，使用redux-thunk将为您节省每个动作创建者文件中的商店导入，并且您将能够拥有多个商店。 这种方法还使您有机会编写更少的代码并避免使用意大利面条代码。 许多redux开发人员不喜欢导入存储并手动调度，因为如果代码严重分离，它可以创建循环依赖关系（从reducers文件中的action creator文件导入操作名称，并从reducers文件导入存储）动作创建者文件）。 此外，直接调度此类操作可能会破坏中间件工作流，即：中间件可能无法处理该操作。

但老实说，如果你还没有看到它的优势，请不要使用它。 如果有一天你遇到异步操作问题，那么redux-thunk可能就是答案。