如何以可維護的方式使用React和Redux thunk處理服務器/連接異常

Question

我正在使用Redux thunk來調度異步操作，例如獲取和發布到服務器。 每個動作創建者調用都會返回一個Promise，該承諾將在ajax完成后解決，神奇的是Redux根據ajax的成功/失敗實際調度了正確的操作來更新狀態。 這樣，我們可以在組件級別自定義調度后回調。

doPostActionCreator(data) {
  return dispatch => {
    return httpService.post(data) {
      .then(response => {
        dispatch({type: POST_SUCCESS, data: response})
        return response
      })
      .catch(error => {
        dispatch({type: POST_ERROR})
        return error
      )}
    }
  }
}

-

componentsDoPostHandler(data) {
  this.props.doPostActionCreator(data)
    .catch(error => {
      alert(error)
      this.setState({...})
    })
}

通過這個簡單的示例，一切都很好，但是當我嘗試通過這種模式引入真正的錯誤處理邏輯時，例如從catch內遞歸地調用componentsDoPostHandler，並在計數器限制超出時中斷，事情開始變得難看，難以維護且易於破壞。 是什么讓認為更加復雜，在我的現實世界中的場景， this.props.doPostActionCreator實際上是一個回調fetchCsrfTokenActionCreator ，其本身也需要同樣的錯誤處理邏輯，試圖獲取X倍和做別的事情如果失敗。 現在，如果一個頁面包含兩個不同的容器，並且它們都引入了這種邏輯，那么在第一個容器執行恢復操作后便分派了后者的恢復操作，因為一旦被稱為動作創建者便無法取消，則這一切都是混亂的。 最后，很難讀取程序的工作方式，並且開始出現“不同步”操作問題，使應用程序處於不一致狀態，並且這些問題很難跟蹤。

這讓我想知道，是否從動作創建者那里返回承諾實際上是一種反模式，從而最終導致代碼無法維護。 我沒有找到任何實際的示例來使用React / Redux堆棧處理異步服務錯誤。 我做錯了嗎？ 是否有一種更干凈的方法來處理異步異常（最好嘗試X次，提醒用戶並返回登錄頁面），以使所有內容保持一致，易於理解，維護並避免異步混亂？

任何有關該主題的真實示例都將受到高度贊賞

Answer 1

我相信您可以在動作創建者內部處理所有重試邏輯。 就是說，我認為您不需要返回任何內容即可嘗試從組​​件中或在調用動作創建者的任何地方調用.catch() 。 請記住，您還可以訪問thunk中的getState()方法，因此在動作創建者的.post().catch() ，您始終可以調度某些內容以指示某些內容已失敗，這可能由reducer處理跟蹤失敗的數量，然后在分派之后調用.getState()以查看發生了多少次失敗並決定從那里進行什么操作（即重試，或者分派另一個操作，表明某件事已失敗太多次了，會更新您的狀態，並允許您的組件從該狀態進行渲染）。

我認為，不用擔心動作創建者之外的.catch() ，就可以簡化您看到的問題。 如果您希望它在多個動作創建者中發生，則可以將其抽象為可為您處理此邏輯的API調用程序方法。