Axios统一错误处理与后置

问题

在进行业务开发的时候，先后端会对接口的数据结构进行约定，若接口有异常，须要将异常信息展现给用户知晓。这个流程里，数据结构是肯定的（事先约定），数据的处理逻辑是相同的（展现给用户），若是在业务代码代码中重复的catch(e) { 展现给用户 }，就很是的不优雅。本着Don't repeat myself（懒）的原则，须要对接口错误进行统一处理。

接下来，我会结合具体的业务场景，讲一讲个人解决方案。

业务场景

1. 后端经过http状态标识接口状态，错误信息在response的data里
2. 前端的处理逻辑是使用element-ui的Message展现错误信息
3. 使用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的参数中添加控制函数使得业务代码能够决定是否展现统一错误处理。稍做抽象与封装就能够造成一个业务无关、框架无关的统一错误处理方案。