WeChatアプレットにおけるフォーム検証機能の実装例

WeChat ミニ プログラムで実装するのが最も難しい公共事業は何ですか?この記事では、主に WeChat アプレットがフォーム検証機能を実装する方法を紹介します。興味のある方は、

ミニ プログラム SDK バージョン 1.4

フォーム検証の難易度を参照してください。聞きたいのですが、WeChat ミニ プログラムで実装するのに最も難しい公共事業は何ですか?それはフォーム検証であるべきであり、それ以外のものではありません。その理由は次のとおりです。
フォームコンポーネントの数が 11 に達し、全種類のコンポーネントの中で 1 位にランクされます。幸いなことに、それらすべてを検証する必要はありません。

これらのコンポーネントにはさまざまな操作方法があり、スライド、(複数行)入力、クリック、クリック+スライドに分類できます。

同じコンポーネントであっても、ビジネスシナリオの違いにより検証ルールも異なります。

さらに問題なのは、これらのコンポーネントが頻繁にリンクされたり検証されたりすることです。

…
しかし、単純ではない静的ページであり、ユーザーとの対話が多い小さなプログラムであるため、フォーム検証は非常に一般的な機能です: ログイン、登録、新規追加、編集…

要するに: フォームコンポーネントの多様性X 検証ルールの多様性 = 複雑な公共事業

このような難しい問題をどうやって解決できるでしょうか?

コンポーネント化を試してみる

近年のフロントエンド開発のトレンドに注目していると、次のことを実現するために必ず「コンポーネント化」を考えるでしょう:
各フォームコンポーネントのビュー、スタイル、検証ロジックをカプセル化する別のビジネスコンポーネントに分割し、それを直接呼び出します。

しかし、物事はそれほど単純ではないようです。

n 個のネイティブ コンポーネントを抽象化し、n 個の検証ルールを追加し、コンポーネント間の関係を n 倍 (完全に配置) することを考慮すると、複雑さは少なくとも n³ に達します。

そして、各コンポーネントの検証の失敗または成功を親コンポーネントに通知して、エラー メッセージを表示したり、次の手順を実行したりできるようにする必要があります。

これでは問題が解決しないだけでなく、これらのパブリック フォーム コンポーネントが非常に複雑になり、混乱を招きます。

非コンポーネント化を試してみましょう

元のアイデアがうまくいかないので、出発点に戻って、コアを抽象化する必要があるものを見てみましょう。
それは、ビュー層の要素スタイルとロジック層の検証ルールの 2 つにすぎません。

ネイティブ フォーム コンポーネントをカプセル化すると複雑さが大幅に増加することは前述しましたが、それを放棄するだけで、複雑さは瞬時に 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>

この場合、検証ルールとコンポーネントの関連付けの間に残る問題は 2 つだけになります。

検証ルールは、拡張可能で構成可能であることが理想的です。

拡張可能。ビジネスが成長するにつれて、既存のルールを変更せずに新しい検証ルールを追加できます。

設定可能。フォーム コンポーネントごとに、異なる単一または複数の検証ルールを個別に構成できます。

それを定義可能にする方法は?統一されたフォームを使用してください。例:

/*
统一的格式：
[规则名]: {
 rule: [校验方式]
 msg: [错误信息]
}
*/
const validators = {
 // 简单的校验用正则
 required: {
  rule: /.+/,
  msg: '必填项不能为空'
 },
 // 复杂的校验用函数
 same: {
  rule (val='', sVal='') {
   return val===this.data[sVal]
  },
  msg: '密码不一致'
 }
 ...
}

設定可能にするにはどうすればよいですか?この構成では配列のような形式がサポートされており、統一された関数を使用してこれらの検証ルールを順番に読み取って 1 つずつ検証します。

設定されたルールはネイティブ フォーム コンポーネント上にある必要があり、コンポーネントの値はイベント オブジェクトを通じてのみ取得できます。

検証のためにイベントを直接バインドすると、親ページが値を取得できなくなるため、イベントを親ページにバインドして値を渡し、イベントオブジェクトと実行環境に渡して処理するのが最善です:

/*
校验函数部分代码
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(&#39;=&#39;)[0]
  let ruleValue = validator[i].split(&#39;=&#39;)[1]
  let rule = validators[ruleName].rule || /.*/
  if (&#39;function&#39; === typeof rule) {
   rule.call(context, value, ruleValue) ? &#39;&#39; : validators[ruleName].msg
  } else {
   rule.test(value) ? &#39;&#39; : validators[ruleName].msg
  }
 }
 ...
}

呼び出すのも簡単です。 固定フォーマットに従って対応するスタイルを追加し、検証ルールを設定して、検証関数を呼び出すだけです。

りー

概要

以上がWeChatアプレットにおけるフォーム検証機能の実装例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。