海阔天空的云

我们在自己的世界里独自狂欢

0%

前端页面的异常处理

起因

其实最近一段时间,就是一直在写前端业务代码,很多人可能觉得前端业务代码,就像是茅坑里的石头又臭又硬,写这种代码并不能获得太多成就感,而更愿意去写那些所谓框架性的代码,更能够从中获得成就感,满足感,这种观点我不做评论。只是想结合我自己最近的经历,谈一谈写前端业务代码遇到的问题。

我认为最常遇到的问题,其实就是各种异常处理了。一个比较规范的产品流,应该由产品经理,设计师,前端开发,后端开发,测试人员这些成员共同完成,产品经理在考虑产品的时候,往往也只是会从最正常的产品使用过程去考虑,设计师在接到产品经理的需求后,设计产品的时候,也往往是按常规操作流去设计产品。举个例子,说一个我自己曾经遇到的产品例子,比如想要实现一个门店自助下单结账的产品,我们通常最先想到的产品使用流程是,

顾客定位门店 =》 扫描商品条码 =》 将商品加入购物车 =》去结算商品,下单 =》 支付 =》 离开门店

这样一个流程,如果顺利的话,可以很顺畅。但是世事难料。我们也会发现,产品也像人生一样,并非一帆风顺,所以,很可能出现各种各样的情况。比如说,

  • 如果顾客定位错了,定位到了其他门店怎么办?
  • 如果顾客扫描的商品,没有在线上商品数据库里怎么办
  • 如果顾客下单支付失败怎么办?

我这里只是列出来了几种情况,事实上还有很多种情况。 我印象当中,当四年以前,我的同事在考虑这个产品的时候,这些坑,都是实际遇到过的。由于一开始并没有想到会有这些坑,他在写代码的时候,就是有遇到这些坑,本来他是按照一个正常的工作流去做的,后来才考虑到各种异常情况,实际结果就是在处理异常时,花费了很多时间精力。

其实我后来做了很多业务开发,也是总结了一下,一半正常工作流的开发时间往往只占整个开发周期的很小一部分,估计也就是1/3的时间。剩下的大部分时间精力,都是投入到了处理各种异常,或者特殊情况当中。

那么都有那些异常呢

接口异常

当现在越来越多的项目采取前后端分离的工作模式去做的时候,接口异常也就摆在了前端工程师的面前。前端工程师,不要以为接口报错就和自己没有关系,身为前端工程师,当然有责任在接口报错的时候,给用户一个比较清晰的提示。这个时候,又要分情况去考虑。首先,也许我们的前端项目为了省事,或者说为了框架性地处理,会选择在框架内部进行全局性地接口报错异常处理,一个常见的例子,就是只要报错,就给用户弹出弹窗提示,这本身无可厚非。然而,也有很多业务场景,我们并不需要给用户弹出弹窗提示。因此,我们首先需要将弹窗提示禁掉,接下来还需要对这些异常处理做额外的工作。

比如,我们的接口报错,我们根据接口提示,发现数据已经被删除,或者没有权限访问,那么,可以基于此判断,给用户一个404的提示。直接显示在页面当中,而不仅仅是给用户一个弹窗。

我自己前不久,写了一个列表页的业务,左侧侧边栏是一个列表,通过选中列表中的某个项目,可以在右侧查看这个项目的具体详情。这个业务,有点类似于Youtube的订阅列表页面,当我在订阅列表中选中一个Youtuber 的时候,我就可以在右侧看到他最近上传的视频。

这个工作流看起来也并不复杂,但是也会有坑,比如左侧列表接口数据访问失败怎么办,右侧单个项目详情数据访问失败怎么办。Youtube 的效果在我看来有一点不完美,但是其实是让开发简化的,他如果出现左侧列表数据访问失败的情况,左右两边都会出现一个页面加载错误,please reload。我是觉得这样的设计有些啰嗦了,其实一个please reload就足够了。我是后来才发现youtube这样设计的,而我们当时的做法,就是只在右侧出现一个please reload。

理想情况之下,我们是可以根据接口的报错状态码来大概的得出一个结论的。如果是404,我们就直接在界面上提示用户这个资源已经被删除了。如果是403,可能就是没有权限访问。通过这些状态码,可以让我们给用户更清晰的提示,也就能够让用户得到更准确的反馈。

表单提交异常

很多时候,接口并没有异常,但是如果按照某个表单数据提交,后端就一定会报错。这个时候,我们往往会防患于未然。这是由某个表单的特征决定的,这些特征往往包括,对数据数量的限制,对单个数据长度的限制,对可选项必填项的限制等等。举例来说,如果我们有一个项目,要求最多只能有10个人参加,那么当我们选中了10个人之后,就不应该再选中第十一个人了。前端如果已经知道了后端的校验规则,就完全没有必要让错误的表单数据提交上去送死,而应该在前端就进行校验。所以 ,前端的很多工作,就是在处理表单提交的各种异常。我们熟悉了这些异常,不惧怕它,甚至能够运用一些公共组件去更好的应对他,才是取胜之道。

结论

如果能够在思考前端业务开发的时候,就想好可能会遇到的业务上的各种坑,其实是能够避免很多问题的。而这里的坑,其实也就是我上文提到的各种异常情况了。我个人的判断是,在前后端分离的大背景下,接口异常这个错误,是最经常遇到的问题。能够在思考业务的时候,就优先想到这一点,并基于此,推动产品和设计进行完善,其实是很重要的一件事情。事实上,也的确如此,前面已经提到产品经理和设计师往往只会去考虑最普遍的工作流,而很少去考虑各种意外。我们则是需要在这个时候给他们提个醒。这样也能够推动这个产品的进步。