在 redux 中使用 thunk 中间件比使用常规函数作为异步动作创建者有什么好处? [英] What are the benefits of using thunk middleware in redux over using regular functions as async action creators?
问题描述
我已经使用 redux 大约两个月了，最近才开始探索处理异步行为(例如获取数据)的不同方法.它出现在 documentation 和 在 GitHub 上讨论 使用 thunk 中间件 这是一个非常简单的概念，但是我不确定我是否理解将执行异步状态机的责任交给 redux 中间件的好处，当一个简单的独立功能可以已经用过了.
I've been using redux for about two months now and have just recently started getting into exploring different ways of dealing with asynchronous behavior such as fetching data. It appears from the documentation and from discussions on GitHub that the standard way of doing this by using the thunk middleware which is a pretty simple concept however I'm not sure if I understand the benefit in handing the responsibility of executing async state machines to redux middleware when a simple independent function could have been used.
function fetchPosts(reddit) {
return dispatch => {
dispatch(requestPosts(reddit))
return fetch(`http://www.reddit.com/r/${reddit}.json`)
.then(response => response.json())
.then(json => dispatch(receivePosts(reddit, json)))
}
}
那么也许在 ReactJS 组件中可能会有一个按钮，如下所示.
Then perhaps in a ReactJS component one may have a button such as the one below.
<button onClick={() => this.props.dispatch(fetchPosts(this.props.reddit))} />
这个按钮在点击时调用异步动作创建者 requestPosts，它返回一个接受 dispatch 的函数，并负责执行任何可能有副作用和还调度可能导致的真实操作.
This button when clicked calls the async action creator requestPosts which returns a function that accepts the dispatch and is responsible for carrying out any async code which may have side effects and also dispatching the true actions that may result.
虽然上述内容完全可以理解，但不清楚为什么人们不喜欢只做一些更简单的事情，如下例所示.
While the above is completely understandable it's unclear why one would not prefer just to do something slightly more simplistic like in the example below.
function fetchPosts(dispatch, reddit) {
dispatch(requestPosts(reddit))
return fetch(`http://www.reddit.com/r/${reddit}.json`)
.then(response => response.json())
.then(json => dispatch(receivePosts(reddit, json)))
}
调用 fetchPosts 函数并将调度作为参数传递.
<button onClick={() => fetchPosts(this.props.dispatch, this.props.reddit)} />
结论
基于并排的两个示例，我看不出使用 thunk 中间件的异步动作创建者如何给我买任何东西，并且它在设置中间件时需要增加复杂性，并引入了两种动作创建者 (1) 纯函数返回要调度的单个动作 (2) 不纯的函数，这些函数会将动作和其他可能的 thunk 反馈到调度程序中.我觉得我在这里遗漏了一些可以解释在 redux 中调度除不可变操作以外的其他内容的好处.
Conclusion
Based on the two examples side by side I don't see how the async action creator using thunk middleware buys me anything and it requires added complexity in setting up the middlware and introduces two varieties of action creators (1) pure functions which return a single action to be dispatched (2) impure functions that will feedback actions and perhaps other thunks into the dispatcher. I feel like I'm missing something here which would explain the benefits of dispatching something other than an immutable action in redux.
推荐答案
这是一个很好的领域.我想说异步动作创建者不是特别满意是一种普遍的看法，但有充分的理由更喜欢 Redux Thunk 而不是完全手动的方法.但这只是许多可能的方法之一.请参阅为什么我们需要异步中间件Redux 中的流程?.
This is very well tread territory. I'd say that it's a common sentiment that async action creators aren't particularly satisfying, but there are good reasons to prefer Redux Thunk to the completely manual approach. But it is just one of a number of possible approaches. See Why do we need middleware for async flow in Redux?.
我认为从长远来看，社区可能会选择 Redux Thunk 以外的其他东西，但它的简单性使它成为一个很好的起点.
I think the community will probably settle on something other than Redux Thunk in the long run, but its simplicity makes it a good starting point.
这篇关于在 redux 中使用 thunk 中间件比使用常规函数作为异步动作创建者有什么好处?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
