微信小程序?qū)崿F(xiàn)表單校驗功能

來源：懂視網(wǎng) 責(zé)編：小采時間：2020-11-27 22:31:42

微信小程序?qū)崿F(xiàn)表單校驗功能

微信小程序?qū)崿F(xiàn)表單校驗功能:小程序SDK版本 1.4 表單校驗之難如果要問微信小程序最難實現(xiàn)的公共業(yè)務(wù)是什么？應(yīng)該是表單校驗，沒有之一。原因如下：表單組件在數(shù)量上達(dá)到11個，居各類組件之首。當(dāng)然幸運的是，并不是所有的都需要校驗。而這些組件操作方式多樣，可分為滑動、（多行）輸

推薦度：

點擊下載本文 文檔為doc格式

導(dǎo)讀微信小程序?qū)崿F(xiàn)表單校驗功能:小程序SDK版本 1.4 表單校驗之難如果要問微信小程序最難實現(xiàn)的公共業(yè)務(wù)是什么？應(yīng)該是表單校驗，沒有之一。原因如下：表單組件在數(shù)量上達(dá)到11個，居各類組件之首。當(dāng)然幸運的是，并不是所有的都需要校驗。而這些組件操作方式多樣，可分為滑動、（多行）輸

小程序SDK版本 1.4

表單校驗之難

如果要問微信小程序最難實現(xiàn)的公共業(yè)務(wù)是什么？應(yīng)該是表單校驗，沒有之一。原因如下：

表單組件在數(shù)量上達(dá)到11個，居各類組件之首。當(dāng)然幸運的是，并不是所有的都需要校驗。
而這些組件操作方式多樣，可分為滑動、（多行）輸入、點擊、點擊+滑動。
即使是同一個組件，因為業(yè)務(wù)場景不同就會有不同的校驗規(guī)則。
更麻煩的是，這些組件之間經(jīng)常還會聯(lián)動或者關(guān)聯(lián)校驗。
…
但是，作為一個非簡單靜態(tài)頁面，有著較多用戶交互的小程序，表單校驗又是一個非常常用的功能：登錄、注冊、新增、編輯…

總而言之：表單組件的多樣性 X 校驗規(guī)則的多樣性 = 復(fù)雜的公共業(yè)務(wù)

這么棘手的問題我們怎么來解決它呢？

嘗試組件化

如果你關(guān)注近年前端發(fā)展趨勢，一定會想到“組件化”來實現(xiàn)：

把每個表單組件的視圖、樣式、校驗邏輯封裝成單獨的業(yè)務(wù)組件，然后直接調(diào)用。

可事情似乎沒這么簡單。

如果考慮把n個原生組件抽象出來，配上n個校驗規(guī)則，再乘以組件之間的關(guān)系n（的全排列），復(fù)雜度至少達(dá)到n³。

而且每個組件的校驗失敗或成功都要通知父組件，以便顯示錯誤信息或者進(jìn)行下一步操作。

這樣不但沒有解決問題，反而使得這些公用的表單組件過于復(fù)雜，耦合混亂。

嘗試非組件化

既然原先的思路行不通，再來回到出發(fā)點，看看我們最核心的需要被抽象出來的是什么。

無非是兩樣?xùn)|西：視圖層的元素樣式和邏輯層的校驗規(guī)則。

上面說到封裝原生表單組件會極大的增加復(fù)雜度，索性放棄它，復(fù)雜度瞬間可以下降到n²。

但同時我們又要保持樣式統(tǒng)一，也就是我們常說的風(fēng)格一致。

比如輸入框該多高，錯誤提示怎么顯示，字體大小顏色…之類的。

這個好辦，我們把樣式類寫入一個公共樣式文件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;
}
...

我們使用的時候只需要在對應(yīng)的元素上添加相應(yīng)的樣式即可。比如：

// xxx.wxml
<form class="form">
 <view class="form-title">請輸入手機(jī)號</view>
 <view class="form-line">
 <label class="label">手機(jī)</label>
 <view class="form-control">
 <input class="f-1 va-m input" />
 </view>
 </view>
 ...
</form>

那么接下來我們只剩下校驗規(guī)則和組件關(guān)聯(lián)關(guān)系之間這兩個難題了。

校驗規(guī)則理想的狀態(tài)是可擴(kuò)展和可配置。

可擴(kuò)展。隨著業(yè)務(wù)的增長，在不修改已有規(guī)則情況可以新增校驗規(guī)則。

可配置?？蓡为殲槊總€表單組件配置不同的單個或多個校驗規(guī)則。

如何做到可定義？用統(tǒng)一的形式即可。比如：

/*
統(tǒng)一的格式：
[規(guī)則名]: {
 rule: [校驗方式]
 msg: [錯誤信息]
}
*/
const validators = {
 // 簡單的校驗用正則
 required: {
 rule: /.+/,
 msg: '必填項不能為空'
 },
 // 復(fù)雜的校驗用函數(shù)
 same: {
 rule (val='', sVal='') {
 return val===this.data[sVal]
 },
 msg: '密碼不一致'
 }
 ...
}

如何做到可配置？配置上支持類似數(shù)組的形式，然后用統(tǒng)一的函數(shù)依次讀取這些校驗規(guī)則，逐個校驗。

配置的規(guī)則肯定是在原生表單組件上，至于組件的值也只能通過事件對象獲取。

如果直接綁定事件進(jìn)行校驗會阻礙父頁面獲取值，所以最好由父頁面綁定事件傳值，并且傳入事件對象和執(zhí)行環(huán)境進(jìn)行處理：

/*
校驗函數(shù)部分代碼
e 事件對象
context 頁面對象函數(shù)執(zhí)行的上下文環(huán)境
*/
let validate = (e, context) => {
 // 從事件對象中獲取組件的值
 let value = (e.detail.value || '').trim()
 // 從事件中獲取校驗規(guī)則名稱
 let validator = e.currentTarget.dataset.validator ? e.currentTarget.dataset.validator .split(',') : []
 // 遍歷規(guī)則進(jìn)行校驗
 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
 }
 }
 ...
}

調(diào)用起來也非常簡單，按照固定的格式加上對應(yīng)的樣式，配置校驗規(guī)則，然后調(diào)用校驗函數(shù)。

// 部分代碼示例
// page.wxml
<form>
 <!-- 一個表單組件 -->
 <view class="form-line">
 <label class="label">授權(quán)手機(jī)</label>
 <view class="form-control">
 <!-- 校驗規(guī)則：必須填寫，且為電話號碼 -->
 <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}}" />
 <!-- 錯誤圖標(biāo) -->
 <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)
}

上面的代碼中省略了校驗錯誤提示和非空校驗。詳細(xì)代碼請查看GitHub倉庫：

https://github.com/yalishizhude/miniprogram-seed.git

總結(jié)

寫代碼最然總是要抱著最美好的想法，但同時也要做著最壞的打算。尤其是面對一些底層框架限制的時候。

面對這種情況，我們要從核心需求出發(fā)，把能抽出公用的東西都出來，同時保證可配置、可擴(kuò)展。

好的的架構(gòu)師不但喜歡未開墾的處女地，也應(yīng)不懼布滿雜石亂草的荒野~

歡迎到評論區(qū)留言交流：https://github.com/yalishizhude/webclub-discuss/issues/1

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com