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**** 有了 ****dispatch**** 屬性。
我們為了在不同 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 更適合。