摘要:本著懶的原則,需要對接口錯誤進行統一處理。方案業務代碼直接使用,頂掉統一的錯誤信息。稍作抽象與封裝就可以形成一個業務無關框架無關的統一錯誤處理方案。
問題
在進行業務開發的時候,前后端會對接口的數據結構進行約定,若接口有異常,需要將異常信息展示給用戶知曉。這個流程里,數據結構是確定的(事先約定),數據的處理邏輯是相同的(展示給用戶),如果在業務代碼代碼中重復的catch(e) { 展示給用戶 },就非常的不優雅。本著Don"t repeat myself(懶)的原則,需要對接口錯誤進行統一處理。
接下來,我會結合具體的業務場景,講一講我的解決方案。
后端通過http狀態標識接口狀態,錯誤信息在response的data里
前端的處理邏輯是使用element-ui的Message展示錯誤信息
使用axios
axios可以通過攔截器,在業務代碼處理響應之前對響應進行處理,類似于下面的流程
someAPI() .then(interceptorsFn) .then(業務邏輯)
所以,我們可以在interceptors對響應進行統一處理:
request.interceptors.response.use( (response) => response.data, (error) => { // 針對特定的http狀態碼進行處理 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) } )如何進行特定的錯誤處理
不難看出,上面的方案有一個問題,如果有某個接口需要有業務代碼來展示定制的錯誤信息(這個情況十分常見),如何處理?
naive方案1:業務代碼使用其它的方式展示信息:例如Notify。這個方案被我司產品痛罵,因為破壞了統一的錯誤信息展示,并且此時統一的錯誤信息是一個垃圾信息,沒必要展示。
naive方案2:業務代碼直接使用Message,頂掉統一的錯誤信息。這個方案還是被產品大哥(dog)懟了,因為明顯的用戶體驗不好,錯誤信息出現了閃爍。
帥氣的解決方案3:業務代碼決定是否隱藏統一錯誤提示那么問題來了,由于是先走攔截器,再走業務代碼,如何由業務代碼決定是否隱藏統一錯誤提示呢?
我的辦法是,將統一的錯誤提示使用setTimeout放到下一個loop執行,并通過一個變量標識是否要執行統一錯誤提示。
request.interceptors.response.use( (response) => response.data, (error) => { ... setTimeout(() => { if (tag) { Message.error(msg) } }) } )
接下來,需要考慮的是,如何在業務代碼里改變標識變量
naive方案1:一個全局的變量或者方法這個方案非常的不靠譜,若在其它代碼里改變了這個全局變量,就嗝屁,并且N個接口公用一個標識變量,只能是同一個狀態。
帥氣方案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上添加方法 } )
業務代碼:
someAPIFN() .then() .catch({ data, hideNormalMessage }) { // 業務代碼 hideNormalMessage() }兼容舊代碼
目前的方案需要對現存代碼做修改,對進行特殊處理的接口添加hideNormalMessage()。如果不想全局搜索添加代碼(懶),可以根據業務來進行兼容。下面講一下我結合業務代碼進行的兼容處理(非常不推薦)。
request.interceptors.response.use( (response) => response.data, (error) => { // warning,和業務代碼深度耦合,不推薦 const hasMessageBeforeCatch = !!document.querySelector(".el-message") ... let isShowNormalError = true const hideNormalError = () => isShowNormalError = false setTimeout(() => { const hasMessageAfterCatch = document.querySelector(".el-message") // 調用catch前沒有message,調用catch后有message,表示message是在catch過程中產生 const madeMessageWhenCatch = !hasMessageBeforeCatch && hasMessageAfterCatch if (isShowNormalError && !madeMessageWhenCatch) { Message.error(msg) } }) return Promise.reject({ ...error.response, hideNormalMessage }) // 在error.response上添加方法 } )
邏輯:如果在catch中使用了Message,就不展示統一錯誤處理
總結這個解決方案的關鍵在于使用setTimeout使得統一錯誤處理“落后”于業務代碼,并在Promise.reject的參數中添加控制函數使得業務代碼可以決定是否展示統一錯誤處理。稍作抽象與封裝就可以形成一個業務無關、框架無關的統一錯誤處理方案。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/97977.html
摘要:今天松哥就帶大家來看看的使用。此時啟動前端項目,就可以順利發送網絡請求了。松哥將自己封裝的網絡請求庫已經放在上,歡迎大家參考。前端網絡訪問,主流方案就是 Ajax,Vue 也不例外,在 Vue2.0 之前,網絡訪問較多的采用 vue-resources,Vue2.0 之后,官方不再建議使用 vue-resources ,這個項目本身也停止維護,目前建議使用的方案是 axios。今天松哥就帶大...
摘要:攔截重復請求如何標識每個請求下面函數,通過一個請求參數中的請求傳遞參數或請求傳遞參數來表示每一個請求。 一直想封裝一下 axios, 可以方便項目中使用,今天有時間,就好好研究了一下。 源碼: // util/axios.js import axios from axios const pending = {} const CancelToken = axios.CancelTok...
摘要:請求和返回數據攔截,統一請求報錯提示官方文檔英文文檔中文文檔請求和返回攔截,添加統一的報錯信息請求的配置可以通過閱讀官方文檔來進行配置。寫好之后,在寫發送請求的文件中引用就可以了。攔截所有有請求與回復請求錯誤,請重試請求錯誤,請重試 axios請求、和返回數據攔截,統一請求報錯提示 官方文檔 https://github.com/axios/axios 英文文檔 https://w...
摘要:使用了攔截器處理相關問題,這樣就不再需要使用來做錯誤的處理。萬惡的攔截器一些處理無論是對成功的處理還是對失敗的處理,如果攔截器不拋出錯誤,那么終將還會執行里面處理請求成功的函數,即使你返回。 一 前言 本文適合剛接觸axios或者使用過幾次的同學來分享交流一些入門經驗,本文同樣適用熟悉axios的同學來作為參考手冊。默認你已經看過axios的相關文檔:axios文檔 GitHub,通過...
摘要:如果用戶已經登錄,則順利進入路由,否則就進入登錄頁面。如果全部鉤子執行完了,則導航的狀態就是確認的。通過這個字段來判斷該路由是否需要登錄權限。還有一種情況便是當前失效了,但是依然保存在本地。通過配置,當后端接口返回未授權,讓用戶重新登錄。 vue+axios 前端實現登錄攔截(路由攔截、http攔截) 一、路由攔截登錄攔截邏輯第一步:路由攔截首先在定義路由的時候就需要多添加一個自定義字...
閱讀 1120·2021-11-25 09:43
閱讀 1569·2021-10-25 09:47
閱讀 2466·2019-08-30 13:46
閱讀 753·2019-08-29 13:45
閱讀 1280·2019-08-26 13:29
閱讀 2990·2019-08-23 15:30
閱讀 1103·2019-08-23 14:17
閱讀 1325·2019-08-23 13:43