問題
創新互聯公司主要從事成都網站設計、成都網站制作、網頁設計、企業做網站、公司建網站等業務。立足成都服務潁州,10年網站建設經驗,價格優惠、服務專業,歡迎來電咨詢建站服務:13518219792
在進行業務開發的時候,前后端會對接口的數據結構進行約定,若接口有異常,需要將異常信息展示給用戶知曉。這個流程里,數據結構是確定的(事先約定),數據的處理邏輯是相同的(展示給用戶),如果在業務代碼代碼中重復的catch(e) { 展示給用戶 },就非常的不優雅。本著Don't repeat myself(懶)的原則,需要對接口錯誤進行統一處理。
接下來,我會結合具體的業務場景,講一講我的解決方案。
業務場景
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的參數中添加控制函數使得業務代碼可以決定是否展示統一錯誤處理。稍作抽象與封裝就可以形成一個業務無關、框架無關的統一錯誤處理方案。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持創新互聯。
網站題目:詳解Axios統一錯誤處理與后置
網頁網址:http://vcdvsql.cn/article26/pdeecg.html
成都網站建設公司_創新互聯,為您提供網站收錄、營銷型網站建設、網站導航、外貿建站、自適應網站、電子商務
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯