使用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可能就是答案。