• <fieldset id="8imwq"><menu id="8imwq"></menu></fieldset>
  • <bdo id="8imwq"><input id="8imwq"></input></bdo>
    最新文章專題視頻專題問答1問答10問答100問答1000問答2000關鍵字專題1關鍵字專題50關鍵字專題500關鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關鍵字專題關鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
    問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
    當前位置: 首頁 - 科技 - 知識百科 - 正文

    微信小程序實現表單校驗功能

    來源:懂視網 責編:小采 時間:2020-11-27 22:31:42
    文檔

    微信小程序實現表單校驗功能

    微信小程序實現表單校驗功能:小程序SDK版本 1.4 表單校驗之難 如果要問微信小程序最難實現的公共業務是什么?應該是表單校驗,沒有之一。原因如下: 表單組件在數量上達到11個,居各類組件之首。當然幸運的是,并不是所有的都需要校驗。 而這些組件操作方式多樣,可分為滑動、(多行)輸
    推薦度:
    導讀微信小程序實現表單校驗功能:小程序SDK版本 1.4 表單校驗之難 如果要問微信小程序最難實現的公共業務是什么?應該是表單校驗,沒有之一。原因如下: 表單組件在數量上達到11個,居各類組件之首。當然幸運的是,并不是所有的都需要校驗。 而這些組件操作方式多樣,可分為滑動、(多行)輸

    小程序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;
    }
    ...

    我們使用的時候只需要在對應的元素上添加相應的樣式即可。比如:

    // 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>
    

    那么接下來我們只剩下校驗規則和組件關聯關系之間這兩個難題了。

    校驗規則理想的狀態是可擴展和可配置。

    可擴展。隨著業務的增長,在不修改已有規則情況可以新增校驗規則。

    可配置。可單獨為每個表單組件配置不同的單個或多個校驗規則。

    如何做到可定義?用統一的形式即可。比如:

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

    如何做到可配置?配置上支持類似數組的形式,然后用統一的函數依次讀取這些校驗規則,逐個校驗。

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

    如果直接綁定事件進行校驗會阻礙父頁面獲取值,所以最好由父頁面綁定事件傳值,并且傳入事件對象和執行環境進行處理:

    /*
    校驗函數部分代碼
    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
     }
     }
     ...
    }


    調用起來也非常簡單,按照固定的格式加上對應的樣式,配置校驗規則,然后調用校驗函數。

    // 部分代碼示例
    // 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

    總結

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

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

    好的的架構師不但喜歡未開墾的處女地,也應不懼布滿雜石亂草的荒野~

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

    聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

    文檔

    微信小程序實現表單校驗功能

    微信小程序實現表單校驗功能:小程序SDK版本 1.4 表單校驗之難 如果要問微信小程序最難實現的公共業務是什么?應該是表單校驗,沒有之一。原因如下: 表單組件在數量上達到11個,居各類組件之首。當然幸運的是,并不是所有的都需要校驗。 而這些組件操作方式多樣,可分為滑動、(多行)輸
    推薦度:
    • 熱門焦點

    最新推薦

    猜你喜歡

    熱門推薦

    專題
    Top
    主站蜘蛛池模板: 99国产精品私拍pans大尺度| 国产精品 羞羞答答在线| 97精品一区二区视频在线观看| 国产精品人人做人人爽人人添| 国产精品久久久久jk制服| 亚洲精品国产日韩无码AV永久免费网| 四虎精品成人免费观看| 久久99精品久久只有精品| 亚洲精品老司机在线观看| 精品国产国产综合精品| 青青草精品视频| 国产精品久久一区二区三区| 久久久久人妻一区精品性色av| 亚洲?V乱码久久精品蜜桃 | 中文字幕一精品亚洲无线一区| 国产成人久久久精品二区三区| 97视频在线观看这里只有精品 | 国产精品久久久久久久午夜片 | 欧美精品亚洲日韩aⅴ| 国产精品免费在线播放| 亚洲精品理论电影在线观看| 国产精品久久成人影院| 成人区人妻精品一区二区不卡视频 | 91精品国产91久久| 亚洲av永久无码精品网站| 国产精品va久久久久久久| 国内揄拍高清国内精品对白| 无码精品人妻一区二区三区中| 国内精品视频九九九九| 国产高清精品在线| 91精品国产91久久久久久青草| 国产精品一区二区不卡| 国产精品视频a播放| 国产精品成人观看视频免费| 国产成人精品精品欧美| 99久久免费国产精精品| 国产精品视频网站你懂得| 欧美韩国精品另类综合| 911亚洲精品不卡| 国产精品午夜福利在线无码 | CAOPORM国产精品视频免费 |