詳解Axios統(tǒng)一錯誤處理與后置

更新時間：2018年09月26日 10:10:00 作者：呱呱呱

這篇文章主要介紹了詳解Axios統(tǒng)一錯誤處理與后置，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧

問題

在進行業(yè)務開發(fā)的時候，前后端會對接口的數(shù)據(jù)結構進行約定，若接口有異常，需要將異常信息展示給用戶知曉。這個流程里，數(shù)據(jù)結構是確定的（事先約定），數(shù)據(jù)的處理邏輯是相同的（展示給用戶），如果在業(yè)務代碼代碼中重復的catch(e) { 展示給用戶 }，就非常的不優(yōu)雅。本著Don't repeat myself（懶）的原則，需要對接口錯誤進行統(tǒng)一處理。

接下來，我會結合具體的業(yè)務場景，講一講我的解決方案。

業(yè)務場景

后端通過http狀態(tài)標識接口狀態(tài)，錯誤信息在response的data里
前端的處理邏輯是使用element-ui的Message展示錯誤信息
使用axios

axios可以通過攔截器，在業(yè)務代碼處理響應之前對響應進行處理,類似于下面的流程

someAPI()
  .then(interceptorsFn)
  .then(業(yè)務邏輯)

所以，我們可以在interceptors對響應進行統(tǒng)一處理:

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    // 針對特定的http狀態(tài)碼進行處理
    if (error.response && error.response.status === 401) {
      router.push({ name: 'ssoLogin' })
      return new Promise(() => {}) // pending的promise，中止promise鏈
    }

    .....

    const msg = error.response.data
    Message.error(msg)

    return Promise.reject(error.response)
  }
)

如何進行特定的錯誤處理

不難看出，上面的方案有一個問題，如果有某個接口需要有業(yè)務代碼來展示定制的錯誤信息（這個情況十分常見），如何處理？

naive方案1：業(yè)務代碼使用其它的方式展示信息：例如Notify。
這個方案被我司產(chǎn)品痛罵，因為破壞了統(tǒng)一的錯誤信息展示，并且此時統(tǒng)一的錯誤信息是一個垃圾信息，沒必要展示。

naive方案2：業(yè)務代碼直接使用Message，頂?shù)艚y(tǒng)一的錯誤信息。
這個方案還是被產(chǎn)品大哥（dog）懟了，因為明顯的用戶體驗不好，錯誤信息出現(xiàn)了閃爍。

帥氣的解決方案3：業(yè)務代碼決定是否隱藏統(tǒng)一錯誤提示
那么問題來了，由于是先走攔截器，再走業(yè)務代碼，如何由業(yè)務代碼決定是否隱藏統(tǒng)一錯誤提示呢？

我的辦法是，將統(tǒng)一的錯誤提示使用setTimeout放到下一個loop執(zhí)行，并通過一個變量標識是否要執(zhí)行統(tǒng)一錯誤提示。

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    ...
    setTimeout(() => {
      if (tag) {
        Message.error(msg)
      }
    })
  }
)

接下來，需要考慮的是，如何在業(yè)務代碼里改變標識變量

naive方案1：一個全局的變量或者方法

這個方案非常的不靠譜，若在其它代碼里改變了這個全局變量，就嗝屁，并且N個接口公用一個標識變量，只能是同一個狀態(tài)。

帥氣方案2：

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    ...
    let isShowNormalError = true
    const hideNormalError = () => isShowNormalError = false

    setTimeout(() => {
      if (isShowNormalError) {
        Message.error(msg)
      }
    })

    return Promise.reject({ ...error.response, hideNormalMessage }) // 在error.response上添加方法
  }
)

業(yè)務代碼:

someAPIFN()
  .then()
  .catch({ data, hideNormalMessage }) {
    // 業(yè)務代碼
    hideNormalMessage()
  }

兼容舊代碼

目前的方案需要對現(xiàn)存代碼做修改，對進行特殊處理的接口添加hideNormalMessage()。如果不想全局搜索添加代碼（懶），可以根據(jù)業(yè)務來進行兼容。下面講一下我結合業(yè)務代碼進行的兼容處理（非常不推薦）。

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    // warning，和業(yè)務代碼深度耦合，不推薦
    const hasMessageBeforeCatch = !!document.querySelector('.el-message')
    
    ...

    let isShowNormalError = true
    const hideNormalError = () => isShowNormalError = false

    setTimeout(() => {
      const hasMessageAfterCatch = document.querySelector('.el-message')

      // 調(diào)用catch前沒有message，調(diào)用catch后有message，表示message是在catch過程中產(chǎn)生
      const madeMessageWhenCatch = !hasMessageBeforeCatch && hasMessageAfterCatch

      if (isShowNormalError && !madeMessageWhenCatch) {
        Message.error(msg)
      }
    })

    return Promise.reject({ ...error.response, hideNormalMessage }) // 在error.response上添加方法
  }
)

邏輯：如果在catch中使用了Message，就不展示統(tǒng)一錯誤處理

總結

這個解決方案的關鍵在于使用setTimeout使得統(tǒng)一錯誤處理“落后”于業(yè)務代碼，并在Promise.reject的參數(shù)中添加控制函數(shù)使得業(yè)務代碼可以決定是否展示統(tǒng)一錯誤處理。稍作抽象與封裝就可以形成一個業(yè)務無關、框架無關的統(tǒng)一錯誤處理方案。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章: