redux-thunk 是一個比較流行的 redux 非同步 action 中介軟體，比如 action 中有 setTimeout 或者通過  fetch 通用遠端 API 這些場景，那麼久應該使用 redux-thunk 了。redux-thunk 幫助你統一了非同步和同步 action 的呼叫方式，把非同步過程放在 action 級別解決，對 component 沒有影響。下面通過例子一步步來看看。

非同步方法的呼叫

store.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  store
 
.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

這是一個簡單的例子，他做事情很簡單，5s 後關閉提醒。

在一個被 redux connect 過的 component 中，是如下這個樣子：

this.props.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  this.props.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

本質上兩者沒有區別，只是被 connect 過的 component 中的 this.props

我們為了在不同 component 中重用建立 action 的程式碼，會把他放到一個 action 的 JS 檔案中。

// actions.js
export function showNotification(text) {
  return { type: 'SHOW_NOTIFICATION', text }
}
export function hideNotification() {
  return { type: 'HIDE_NOTIFICATION' }
}

// component.js
import { showNotification, hideNotification } from
 
 '../actions'

this.props.dispatch(showNotification('You just logged in.'))
setTimeout(() => {
  this.props.dispatch(hideNotification())
}, 5000)

當然，如果我們用了 connect 的第二引數把這兩個方法繫結到 component 的 this.props 上，在呼叫時我們又省了一些程式碼量，就像這樣了：

this.props.showNotification('You just logged in.')
setTimeout(() => {
  this.props.hideNotification()
}, 5000)

看起來一切順利，現在有什麼問題呢？

• 在每個使用該功能的 component 中都要寫同樣的程式碼。

• 如果兩個 notification 時間很接近，當第一個結束了之後，dispatch 了 HIDE_NOTIIFICATION 把第二個也錯誤的關閉了。

// actions.js
function showNotification(id, text) {
  return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
  return { type: 'HIDE_NOTIFICATION', id }
}

let nextNotificationId = 0
export function showNotificationWithTimeout(dispatch, text) {
  // Assigning IDs to notifications lets reducer ignore HIDE_NOTIFICATION
  // for the notification that is not currently visible.
  // Alternatively, we could store the interval ID and call
  // clearInterval(), but we’d still want to do it in a single place.
  const id = nextNotificationId++
  dispatch(showNotification(id, text))

  setTimeout(() => {
    dispatch(hideNotification(id))
  }, 5000)
}

為了解決上述問題，我們把這部分邏輯也放到了 action ，並引入了 ID 來解決問題2.

我們愉快的用下面的程式碼呼叫起來：

// component.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')

// otherComponent.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged out.')

我們通過引數把 dispatch 傳入了進去，實際上一般 component 都會有  this.props.dispatch ，但是通常為了測試和 mock 方便，還是傳入進去比較好一點。

// store.js
export default createStore(reducer)

// actions.js
import store from './store'

// ...

let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
  const id = nextNotificationId++
  store.dispatch(showNotification(id, text))

  setTimeout(() => {
    store.dispatch(hideNotification(id))
  }, 5000)
}

// component.js
showNotificationWithTimeout('You just logged in.')

// otherComponent.js
showNotificationWithTimeout('You just logged out.')

如果你的 store 是全域性的也可以這麼幹，不過這樣在 server render 中就不好用了，server render 一般是一個 request 一個 store。

而且一樣的對測試和 mock 都不友好。

引入 redux-thunk

到目前為止，我們還沒有引入 redux-thunk 呢，那我們為什麼要用 redux-thunk 呢？如果你是個小應用，那大可不必使用，如果是個大應用，接著往下看，we talk about redux-thunk.

問題在哪？

• 我們一定要傳入 dispatch ，參考 separate container and presentational components ，我們很難在一個 presentational component 中使用  showNotificationWithTimeout() ,因為不一定有  this.props.dispatch 。

• showNotificationWithTimeout() 不能被 connect 方法繫結到  this.props ，因為他不返回一個 redux action.

• showNotificationWithTimeout() 僅僅是一個 helper 方法，他和 showNotification 同時存在，很容就用錯了。

redux-thunk 怎麼做的？

/ actions.js
function showNotification(id, text) {
  return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
  return { type: 'HIDE_NOTIFICATION', id }
}

let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
  return function (dispatch) {
    const id = nextNotificationId++
    dispatch(showNotification(id, text))

    setTimeout(() => {
      dispatch(hideNotification(id))
    }, 5000)
  }
}

• 如果 redux-thunk 發現 dispatch 了一個函式 dispatch(showNotificationWithTimeout('log in')) ，他會傳給函式一個 dispatch 引數，這解決了 dispatch 不好獲取的問題。

• 他會自己「吃掉」這個函式，不會傳遞給 reduces，防止 reduces 遇到一個函式而不知所措。

我們怎麼呼叫 showNotificationWithTimeout() 呢？

// component.js
this.props.dispatch(showNotificationWithTimeout('You just logged in.'))

我們可以看到，dispatch 一個非同步 action 和 dispatch 一個同步的 action 是一致的，component 不用關係這個 action 是非同步還是同步的，你可以在任何時間修改他。

通過 connect 綁定了這個方法後，完整的例子如下： ``` // actions.js

function showNotification(id, text) { return { type: 'SHOW NOTIFICATION', id, text } } function hideNotification(id) { return { type: 'HIDE NOTIFICATION', id } }

let nextNotificationId = 0 export function showNotificationWithTimeout(text) { return function (dispatch) { const id = nextNotificationId++ dispatch(showNotification(id, text))

setTimeout(() => {
  dispatch(hideNotification(id))
}, 5000)

} }

// component.js

import { connect } from 'react-redux'

// ...

this.props.showNotificationWithTimeout('You just logged in.')

// ...

export default connect( mapStateToProps, { showNotificationWithTimeout } )(MyComponent) ```

在 Trunk 中讀取狀態

有時我們會遇到需要知道當前狀態的情況，除了傳入 dispatch 引數, 還會把  getState 作為第二個引數傳入，放個例子感受一下：

let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
  return function (dispatch, getState) {
    // Unlike in a regular action creator, we can exit early in a thunk
    // Redux doesn’t care about its return value (or lack of it)
    if (!getState().areNotificationsEnabled) {
      return
    }

    const id = nextNotificationId++
    dispatch(showNotification(id, text))

    setTimeout(() => {
      dispatch(hideNotification(id))
    }, 5000)
  }
}

一般場景是斷路器的場景，如果某個遠端呼叫之前查詢一下 cache 等，如果僅僅是用來區分 dispatch 哪個 action，還是把他放到 reducers 更適合。

回顧

今天分享了使用 redux 過程中怎麼處理非同步呼叫的情況，並引入了 thunk 這個框架。後續還會分享一些理念更先進的處理非同步呼叫的框架，比如 redux-saga 和 redux-loop ，敬請期待哦。