摘要:本着懒的原则,需要对接口错误进行统一处理。方案业务代码直接使用,顶掉统一的错误信息。稍作抽象与封装就可以形成一个业务无关框架无关的统一错误处理方案。
问题
在进行业务开发的时候,前后端会对接口的数据结构进行约定,若接口有异常,需要将异常信息展示给用户知晓。这个流程里,数据结构是确定的(事先约定),数据的处理逻辑是相同的(展示给用户),如果在业务代码代码中重复的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的参数中添加控制函数使得业务代码可以决定是否展示统一错误处理。稍作抽象与封装就可以形成一个业务无关、框架无关的统一错误处理方案。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/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拦截) 一、路由拦截登录拦截逻辑第一步:路由拦截首先在定义路由的时候就需要多添加一个自定义字...
阅读 1055·2021-11-25 09:43
阅读 1529·2021-10-25 09:47
阅读 2438·2019-08-30 13:46
阅读 729·2019-08-29 13:45
阅读 1250·2019-08-26 13:29
阅读 2950·2019-08-23 15:30
阅读 1073·2019-08-23 14:17
阅读 1301·2019-08-23 13:43