微信小程序之表单校验功能实现的实例

微信小程序之表单校验功能实现的实例
微信小程序最难实现的公共业务是什么？应该是表单校验，这篇文章主要介绍了微信小程序如何实现表单校验功能，具有一定的参考价值，感兴趣的小伙伴们可以参考一下

微信小程序最难实现的公共业务是什么？应该是表单校验，这篇文章主要介绍了微信小程序如何实现表单校验功能，具有一定的参考价值，感兴趣的小伙伴们可以参考一下

小程序SDK版本 1.4

表单校验之难

如果要问微信小程序最难实现的公共业务是什么？应该是表单校验，没有之一。原因如下：

表单组件在数量上达到11个，居各类组件之首。当然幸运的是，并不是所有的都需要校验。而这些组件操作方式多样，可分为滑动、（多行）输入、点击、点击+滑动。即使是同一个组件，因为业务场景不同就会有不同的校验规则。更麻烦的是，这些组件之间经常还会联动或者关联校验。…但是，作为一个非简单静态页面，有着较多用户交互的小程序，表单校验又是一个非常常用的功能：登录、注册、新增、编辑…

总而言之：表单组件的多样性 X 校验规则的多样性 = 复杂的公共业务

这么棘手的问题我们怎么来解决它呢？

尝试组件化

如果你关注近年前端发展趋势，一定会想到“组件化”来实现：

把每个表单组件的视图、样式、校验逻辑封装成单独的业务组件，然后直接调用。

可事情似乎没这么简单。

如果考虑把n个原生组件抽象出来，配上n个校验规则，再乘以组件之间的关系n（的全排列），复杂度至少达到n³。

而且每个组件的校验失败或成功都要通知父组件，以便显示错误信息或者进行下一步操作。

这样不但没有解决问题，反而使得这些公用的表单组件过于复杂，耦合混乱。

尝试非组件化

既然原先的思路行不通，再来回到出发点，看看我们最核心的需要被抽象出来的是什么。

无非是两样东西：视图层的元素样式和逻辑层的校验规则。

上面说到封装原生表单组件会极大的增加复杂度，索性放弃它，复杂度瞬间可以下降到n²。

但同时我们又要保持样式统一，也就是我们常说的风格一致。

比如输入框该多高，错误提示怎么显示，字体大小颜色…之类的。

这个好办，我们把样式类写入一个公共样式文件form.wxss，然后需要的时候引入，甚至可以全局引入。

// form.wxss.form { display: block; font-size: 28rpx; position: relative;}.form-line { background-color: #fff; border-bottom: 1px solid #e5e5e5; font-size: 34rpx; height: 96rpx; line-height: 96rpx; display: flex; padding: 0 31rpx;}.form-title { box-sizing: border-box; background-color: #efefef; color: #838383; font-size: 28rpx; padding: 31rpx; min-height: 90rpx;}...