如今前端领域是MVVM框架的天下,组件库也层出不穷,但是,并没有一个知名的组件库提供ajax异常的成熟解决方案,所以今天我们就来研讨一下,如何尽量正确地处理异常。
从业务上简单说,凡是code不是200的,都是异常。这里code可以是HTTP状态码,也可以是响应体的code,就不细究了,反正本质没差别。然后,根据code的不同,又可以细分成401 403 404 500等等。
如果你的后端伙伴以HTTP状态码表示404,以响应体code表示其他错误,而且你又无法劝说他们,那么你应在axios的拦截器里把各种情况全考虑进去,比如:
超时很简单,axios也支持,设定超时阈值即可。超时跟无响应的区别是,超时意味着HTTP三次握手成功,但是得不到响应体,浏览器知道接口是存在的,但是响应体又在规定时间内没有拿到。无响应是根本无法HTTP握手,也就无法获知接口存在。
处理超时,通常做法是在拦截器里重新请求一遍,还是超时的话就视为服务器错误。
得不到响应又分成2种,可能是网断了,也可能是服务器停机了。
苛刻地说,你应分辨这2种情况,并给出不同的提示,毕竟网断了,用户可以寻找别的联网方式,而服务器停机了就给个重连按钮,让用户有事没事的尝试重连一下。
关于解决方案,首先说,XHR对象无法区分到底断网还是服务器停机,axios对于2种情况都返回'Network Error'。在得到这个反馈之后,你接下来可以有这2种解决办法:
你可以将
https://api.map.baidu.com/images/blank.gif 改成其他服务器稳定且字节小的图片。或许你可以做一张几字节的图片,传到一个非常牛逼的CDN上。
MDN手册:
https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/connection 它不支持IE,就算你不在乎这一点,那么它是不是一定准呢?对于需要登录的VPN网络,它是否准呢?我也不知道,总体说,它真的不是最佳的方案。我推荐用方案1。
很简单,分为3种:
通常,一个接口,只需要按照其中一种去处理即可,优先级就是上面书写顺序。
容器内错误提示肯定是内容区的接口出错才会出现。
处理方式:
局部报错比较容易理解,比如一个List的接口出错,那么,上策是应当给这个容器尽量撑高到有内容时的高度,然后居中给一个错误图标和错误描述。中策是不考虑有内容时候的高度,只让错误提示和错误描述撑起一定高度即可。都不算错。如果容器很小,比如就是一个3位数值,那么用一个 - 表示错误也可以。
页面整体报错稍微复杂,比如一个左右结构的内容管理系统,前置接口有userInfo接口、全局字典接口、全局路由接口等,这些接口与众不同的地方在于它们是基础接口,它们出错的话,网站干脆就不能用,页面骨架也是错乱的,这种情况下可以有2种解决办法:一是跳转到专门的5xx报错页面,页面中央有错误图标、错误提示,以及“返回上一页”的按钮;二是用白板遮罩覆盖浏览器视口,居中放一个错误图标和错误文字以及“刷新页面”的按钮,本质是用一个fixed的遮罩压住浏览器全部面积。用哪种方案都可。所以你要做的是决定哪些接口属于全局报错,哪些接口属于局部报错,并做不同的处理。
报错内容:
根据ajax异常的分类,可能至少能分出3种:网络错误、服务器宕机、服务器错误。具体用什么图标和文字我就不多说了。
组件化:
容器内报错应尽量组件化。该放返回上一页或刷新按钮的,一定要放按钮。
排他性:
只要做了容器内报错,就不要做另外报错了。这也说明了一点,就是在axios拦截器里弹toast或者modal是愚蠢的方案,我在别的文章也提到过这种观点。不做容器内报错的情况,才应该考虑其他3种情况。
什么样的场景下使用容器隐藏?
比如页面有一个角落显示你的粉丝数、关注数、评论量……。如果有获取到数据,则让这个容器出现,没有的话,则容器就保持隐藏。这一类场景往往应用于非主要内容,比如侧边栏的小内容块。
由于这只适用于非主要内容,那么主要内容也会有它自己的报错,所以,你不必担心用户看不到“网络出错”这类错误提示。
先简单对比一下toast和modal。
很简单,toast就是轻提示,不需要手动关闭,modal就是重提示,需要手动关闭。采用哪个,只要站在用户角度思考问题就好了。比如有人说,异常应当用重提示。可以这么绝对化么?不可以。比如你在某个页面点赞,提示你 “您已经点过赞了” ,这用重提示吗?肯定toast就够了。同样的,成功提示一定用轻提示吗?比如提示 “感谢参与,工作人员将在3~5个工作日内联系你” ,这么长,能toast?能一闪而过?
什么接口适用弹出提示?简单说,只要跟UI显示不相干的,都最好是使用弹出提示。比如这几种场景:
先说上传数据断网之类的错误,通常用modal,因为modal能够拦截用户动作,避免重复上传,而且,还能给用户足够的时间让用户看清楚出错原因,避免无谓的重试。
然后说数据内容错误,无论是表单提交,还是点个赞,错误提示一般用toast,毕竟用户可能只是不小心填错的,看一眼然后赶紧改正就好了。
最后说401错误,有2种做法,一是用modal,因为一般要强制用户转到登录页,但是转之前也得让用户看明白为什么要转,所以可以先modal提示,点击确定就跳转到登录页;二是用toast,但是需要先跳转,然后在登录页上提示toast“请先登录”。
警告条
警告条是可关闭的、永久生命的、又不妨碍用户继续操作的弹出组件,一般在页面顶部,或者在用户操作区域的附近。什么场景用警告条?
比如的MD编辑器,你只要输入,就会自动给服务器发送数据,频率很快,有时候因为网络或者服务器的问题,会出现保存失败的可能性,这时候就会在页面顶部出现一个比较长时间的警告条,告诉你保存失败,但你依然可以继续写,什么时候网络正常了,什么时候toast才会自动消失,当然你也可以手动关闭它。
总之,toast、modal、警告条究竟什么场合使用,要根据产品、业务具体而定,要注意优先使用容器内报错和容器隐藏。