問題

創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)潁州,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792

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

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

業(yè)務(wù)場景

1. 后端通過http狀態(tài)標(biāo)識(shí)接口狀態(tài)，錯(cuò)誤信息在response的data里
2. 前端的處理邏輯是使用element-ui的Message展示錯(cuò)誤信息
3. 使用axios

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

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

所以，我們可以在interceptors對(duì)響應(yīng)進(jìn)行統(tǒng)一處理:

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    // 針對(duì)特定的http狀態(tài)碼進(jìn)行處理
    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)
  }
)

如何進(jìn)行特定的錯(cuò)誤處理

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

naive方案1：業(yè)務(wù)代碼使用其它的方式展示信息：例如Notify。
這個(gè)方案被我司產(chǎn)品痛罵，因?yàn)槠茐牧私y(tǒng)一的錯(cuò)誤信息展示，并且此時(shí)統(tǒng)一的錯(cuò)誤信息是一個(gè)垃圾信息，沒必要展示。

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

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

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

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

接下來，需要考慮的是，如何在業(yè)務(wù)代碼里改變標(biāo)識(shí)變量

naive方案1：一個(gè)全局的變量或者方法

這個(gè)方案非常的不靠譜，若在其它代碼里改變了這個(gè)全局變量，就嗝屁，并且N個(gè)接口公用一個(gè)標(biāo)識(shí)變量，只能是同一個(gè)狀態(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è)務(wù)代碼:

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

兼容舊代碼

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

request.interceptors.response.use(
  (response) => response.data,
  (error) => {
    // warning，和業(yè)務(wù)代碼深度耦合，不推薦
    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)一錯(cuò)誤處理

總結(jié)

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

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持創(chuàng)新互聯(lián)。