小程序SDK版本 1.4
表單校驗之難
如果要問微信小程序最難實現的公共業務是什么?應該是表單校驗,沒有之一。原因如下:
表單組件在數量上達到11個,居各類組件之首。當然幸運的是,并不是所有的都需要校驗。
而這些組件操作方式多樣,可分為滑動、(多行)輸入、點擊、點擊+滑動。
即使是同一個組件,因為業務場景不同就會有不同的校驗規則。
更麻煩的是,這些組件之間經常還會聯動或者關聯校驗。
…
但是,作為一個非簡單靜態頁面,有著較多用戶交互的小程序,表單校驗又是一個非常常用的功能:登錄、注冊、新增、編輯…
總而言之:表單組件的多樣性 X 校驗規則的多樣性 = 復雜的公共業務
這么棘手的問題我們怎么來解決它呢?
嘗試組件化
如果你關注近年前端發展趨勢,一定會想到“組件化”來實現:
把每個表單組件的視圖、樣式、校驗邏輯封裝成單獨的業務組件,然后直接調用。
可事情似乎沒這么簡單。
如果考慮把n個原生組件抽象出來,配上n個校驗規則,再乘以組件之間的關系n(的全排列),復雜度至少達到n³。
而且每個組件的校驗失敗或成功都要通知父組件,以便顯示錯誤信息或者進行下一步操作。
這樣不但沒有解決問題,反而使得這些公用的表單組件過于復雜,耦合混亂。
嘗試非組件化
既然原先的思路行不通,再來回到出發點,看看我們最核心的需要被抽象出來的是什么。
無非是兩樣東西:視圖層的元素樣式和邏輯層的校驗規則。
上面說到封裝原生表單組件會極大的增加復雜度,索性放棄它,復雜度瞬間可以下降到n²。
但同時我們又要保持樣式統一,也就是我們常說的風格一致。
比如輸入框該多高,錯誤提示怎么顯示,字體大小顏色…之類的。
這個好辦,我們把樣式類寫入一個公共樣式文件form.wxss,然后需要的時候引入,甚至可以全局引入。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
// 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 {
background-color: #efefef;
color: #838383;
font-size: 28rpx;
padding: 31rpx;
min-height: 90rpx;
}
...
|
我們使用的時候只需要在對應的元素上添加相應的樣式即可。比如:
1
2
3
4
5
6
7
8
9
10
11
|
// xxx.wxml
<form class="form">
<view class="form-title">請輸入手機號</view>
<view class="form-line">
<label class="label">手機</label>
<view class="form-control">
<input class="f-1 va-m input" />
</view>
</view>
...
</form>
|
那么接下來我們只剩下校驗規則和組件關聯關系之間這兩個難題了。
校驗規則理想的狀態是可擴展和可配置。
可擴展。隨著業務的增長,在不修改已有規則情況可以新增校驗規則。
可配置。可單獨為每個表單組件配置不同的單個或多個校驗規則。
如何做到可定義?用統一的形式即可。比如:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
/*
統一的格式:
[規則名]: {
rule: [校驗方式]
msg: [錯誤信息]
}
*/
const validators = {
// 簡單的校驗用正則
required: {
rule: /.+/,
msg: '必填項不能為空'
},
// 復雜的校驗用函數
same: {
rule (val='', sVal='') {
return val===this.data[sVal]
},
msg: '密碼不一致'
}
...
}
|
如何做到可配置?配置上支持類似數組的形式,然后用統一的函數依次讀取這些校驗規則,逐個校驗。
配置的規則肯定是在原生表單組件上,至于組件的值也只能通過事件對象獲取。
如果直接綁定事件進行校驗會阻礙父頁面獲取值,所以最好由父頁面綁定事件傳值,并且傳入事件對象和執行環境進行處理:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
/*
校驗函數部分代碼
e 事件對象
context 頁面對象函數執行的上下文環境
*/
let validate = (e, context) => {
// 從事件對象中獲取組件的值
let value = (e.detail.value || '').trim()
// 從事件中獲取校驗規則名稱
let validator = e.currentTarget.dataset.validator ? e.currentTarget.dataset.validator .split(',') : []
// 遍歷規則進行校驗
for (let i = 0; i < validator.length; i++) {
let ruleName = validator[i].split('=')[0]
let ruleValue = validator[i].split('=')[1]
let rule = validators[ruleName].rule || /.*/
if ('function' === typeof rule) {
rule.call(context, value, ruleValue) ? '' : validators[ruleName].msg
} else {
rule.test(value) ? '' : validators[ruleName].msg
}
}
...
}
|
調用起來也非常簡單,按照固定的格式加上對應的樣式,配置校驗規則,然后調用校驗函數。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
// 部分代碼示例
// page.wxml
<form>
<!-- 一個表單組件 -->
<view class="form-line">
<label class="label">授權手機</label>
<view class="form-control">
<!-- 校驗規則:必須填寫,且為電話號碼 -->
<input maxlength="11" class="f-1 va-m input" bindblur="validate" type="number" data-name="phone" data-validator="required,phone" confirm-type="next" value="{{phone}}" />
<!-- 錯誤圖標 -->
<icon wx:if="{{form.phone!==undefined}}" type="{{form.phone?'warn':'success'}}" size="16" />
</view>
</view>
...
</form>
// page.js
valid(e) {
this.setData({
[e.currentTarget.dataset.name]: e.detail.value
})
validate(e, this)
}
|
上面的代碼中省略了校驗錯誤提示和非空校驗。詳細代碼請查看GitHub倉庫:
https://github.com/yalishizhude/miniprogram-seed.git
總結
寫代碼最然總是要抱著最美好的想法,但同時也要做著最壞的打算。尤其是面對一些底層框架限制的時候。
面對這種情況,我們要從核心需求出發,把能抽出公用的東西都出來,同時保證可配置、可擴展。
好的的架構師不但喜歡未開墾的處女地,也應不懼布滿雜石亂草的荒野~