Vue Element-ui フォーム検証ルールの実装

1. はじめに

Element-ui フォーム検証ルールを使用すると、ポップアップボックスなしでフォーム項目のすぐ下にエラープロンプトを表示できるため、非常に便利です。

ログインページでフォーム検証を実行した後、フォーム検証ルールをすでに理解したと思いました。しかし、フォーム検証ルールを詳細に使用すると、次の問題が発生しました。

属性値が特定の範囲内にあるかどうかを判断する方法と、この範囲を任意に指定できるかどうかを教えてください。
属性値が特定の値であるかどうかを判断するにはどうすればよいでしょうか?
現在の属性の検証ルールが別の属性の値に依存する場合、複数の属性の共同検証を実行するにはどうすればよいでしょうか?例えば、登録ページでは、IDの種類としてメールアドレス、携帯電話番号、IDカード番号などがあります。異なる種類を選択した場合、IDValue属性の検証ルールが異なります。どのように対処すればよいでしょうか？
2 つのモードでは、同じフォームコンポーネントを入力するときに、一部のフィールドで検証ルールが使用されない場合があります。つまり、ルールのオブジェクトが異なります。この状況にどう対処すればいいのでしょうか?

上記の質問を見ると、自分がまるで初心者のように感じます。このため、検証ルールを一から勉強し、関連ドキュメントを参照する必要がありました。

この記事では、フォーム検証ルールに関する私の経験を共有します。

2. ルール検証の入力モード

2.1 サンプルコード

ルール検証の概要として、ログインページを例に挙げると、コードは次のようになります。

<テンプレート> 
  <div class="ログインコンテナ">    
    <el-form ref="form" :model="form" :rules="rules" label-width="80px" class="login-form">
      <h2 class="login-title">XX 管理システム ログイン</h2>
      <el-form-item label="ユーザー名:" prop="ユーザー名">
        <el-input v-model="form.username"></el-input>
      </el-form-item>
      <el-form-item label="パスワード:" prop="パスワード">
        <el-input v-model="form.password" type="password"></el-input>
      </el-form-item>
      <el-form-item label="検証コード:" prop="verifyCode">
        <el-input v-model="form.verifyCode"></el-input>
        <div class="divVerifyCodeImg" @click="getVerifyCode(true)">
          <img id="verifyCodeImg" style="height:40px; width: 100px; cursor: pointer;" alt="クリックして変更" title="クリックして変更" />
        </div>
      </el-form-item>
      <el-form-item>
        <el-button type="primary" id="login" style="width:160px" @click="submitForm('form')">ログイン</el-button>
      </el-form-item>
    </el-form>
  </div>  
</テンプレート>

<スクリプト>
'vuex' から { mapMutations } をインポートします。
エクスポートデフォルト{
  データ（） {
    戻る {
      形状： {
        ユーザー名: "",
        パスワード: "",
        検証コード: "",
      },
      ルール:
        ユーザー名: [
          {必須: true、メッセージ: "ユーザー名は空欄にできません"、トリガー: 'blur'}、
        ]、
        パスワード: [
          {必須: true、メッセージ: "パスワードは空欄にできません"、トリガー: 'blur'}、
          {最小: 6、最大: 30、メッセージ: "パスワード 6〜30 文字"、トリガー: 'blur'}
        ]、
        検証コード:
          {必須: true、メッセージ: 「確認コードは空欄にできません」、トリガー: 'blur'}、
        ]
      }      
    };   
  },
  メソッド: {
    // ログイン送信 submitForm(formName) { 
      _this = this とします。     
      // 検証を実行する this.$refs[formName].validate(valid => {
        // 検証に合格した場合は true、失敗した場合は false
        （有効）の場合{
          // 検証に合格 // ログイン プロセス // ....
        } それ以外 {
          // 検証に失敗しました console.log('検証に失敗しました');
          false を返します。
        }
      });
    },
  }  
}
</スクリプト>

2.2、フォーム項目

フォーム項目。使用する検証ルールを示します。

 <el-form ref="form" :model="form" :rules="rules" label-width="80px" class="login-form">

:rules="rules" は、検証ルールがルールオブジェクトを使用することを指定します。rules1 などの他の名前を使用することもできます。

2.3. 小道具アイテム

どのフィールドが検証ルールを使用できるかを示すプロパティ項目:

      <el-form-item label="ユーザー名:" prop="ユーザー名">
        <el-input v-model="form.username"></el-input>
      </el-form-item>

prop 項目で指定されたプロパティ値 (ユーザー名など) にも、ルール内に対応する項目がある場合は、そのプロパティ値がルール検証を実行することを意味します。この属性は、フォームのモデル属性にバインドされたデータオブジェクトの属性である必要があります。この場合、データで定義されているフォームです。

      形状： {
        ユーザー名: "",
        パスワード: "",
        検証コード: "",
      },

2.4、ルール項目

ルール項目、つまり検証ルールセットはデータで定義され、その名前はフォームの :rules 属性にバインドされたルールオブジェクトの名前と一致している必要があります。

      ルール:
        ユーザー名: [
          {必須: true、メッセージ: "ユーザー名は空欄にできません"、トリガー: 'blur'}、
        ]、
        パスワード: [
          {必須: true、メッセージ: "パスワードは空欄にできません"、トリガー: 'blur'}、
          {最小: 6、最大: 30、メッセージ: "パスワード 6〜30 文字"、トリガー: 'blur'}
        ]、
        検証コード:
          {必須: true、メッセージ: 「確認コードは空欄にできません」、トリガー: 'blur'}、
        ]
      }

これはオブジェクトであり、各要素のタイプは {property name: [rule]} です。プロパティ名は prop のプロパティ値に対応します。 [rule] はルール配列であり、ルール配列内の各項目はこの属性の検証ルールです。

2.5. ルール項目

ルール項目、つまりルール配列の要素は、この記事で説明する重要な項目です。ここではまず、上記のルールの要素を分析します。

required: 値が必須かどうかを示します。値は true/false です。true の場合、値が必須であることを意味します。値がない場合、チェックは失敗します。false の場合、値は許可されませんが、値がある場合、他のルールの使用には影響しません。
message: プロンプトメッセージ。検証が失敗したときにこのメッセージが表示されます。
トリガー: トリガーモード、値はぼかし/変更、青はフォーカスの喪失を意味し、通常は入力コンポーネントで使用されます。変更は値の変更を意味し、通常は選択ボックスで使用されます。
min: 最小文字列長。
max: 文字列の最大長。

これらの説明により、上記のルールで定義されている各属性の検証ルールを理解することは難しくありません。

2.6. 利用規則

this.$refs['form'].validate(valid => {
        // 検証に合格した場合は true、失敗した場合は false
        （有効）の場合{
          // 検証に合格 } else {
          // 検証に失敗しました}
      });

この検証メソッドでは、リリースされる前にすべての検証ルールに合格する必要があります。このうち、$refs['form']はformのref属性値を指します。

2.7. ルール検証の核心

ルール検証の中核となるのは async-validator プラグインです。公式 Web サイト: https://github.com/yiminghe/async-validator。

Element-UI はこのプラグインを使用してカプセル化します。公式サイト：https://element.eleme.cn/#/zh-CN/component/form.

したがって、双方からの情報が役立つでしょう。

3. ルール検証の高度なモード

3.1. ネストされたオブジェクト属性名

場合によっては、プロパティは単純な属性ではなく、別のオブジェクトにラップされたプロパティです。のように：

      <el-form-item label="ログイン名:" prop="formData.loginName">
        <el-input v-model="form.formData.loginName" :disabled="form.formData.userId != 0"></el-input>
      </el-form-item>

フォームのモデルにバインドされたフォームオブジェクトの形式は次のとおりです。

        形状：{
          // フォームデータフィールド。バックエンドへの送信を容易にするために、UserInfo フィールド formData と同じ名前を付けることをお勧めします: {
            ユーザーID: 0,
            ログイン名: ''、
            パスワード: ''、
            // ...
          },

          // ユーザータイプ選択ボックスの現在の表示値 userTypeLabel: "",
          // ...
        },

現時点では、ルールの要素定義は次の形式にすることはできません。

        フォームデータ.ログイン名: [
          {必須: true、メッセージ: "ログイン名は空にできません"、トリガー: 'blur'}、
        ]、

この方法では、コンパイルでエラーが報告されます。

次の形式を使用する必要があります。

    'formData.ログイン名': [
      {必須: true、メッセージ: "ログイン名は空欄にできません"、トリガー: 'blur'}、
    ]、

つまり、一重引用符または二重引用符で囲んで文字列に変換します。

3.2. カスタムバリデーター

よく使用される正規表現チェック用のバリデータなど、カスタムバリデータに関する情報はインターネット上にたくさんあります。

ルール定義方法:

          'formData.ログイン名': [
            {必須: true、メッセージ: "ログイン名は空にできません"、トリガー: 'blur'}、
            {validator:loginNameValidator、トリガー: 'blur'}
          ]、

'formData.loginName' 属性が loginNameValidator バリデーターを使用することを示します。コードの再利用を考慮すると、カスタムバリデーターは通常、他のページやプロジェクトでの使用を容易にするために js ファイルに分離されます。

/src/common/ ディレクトリに、次のコードを含む validator.js ファイルを作成します。

/* ログイン名の確認 */
エクスポート関数 loginNameValidator(ルール、値、コールバック){
  定数reg = /^[a-zA-Z][\w-.@]*$/;
  if(値 == '' || 値 == 未定義 || 値 == null){
    折り返し電話（）;
  }それ以外 {  
    if (!reg.test(値)){
      callback(new Error('要件: 英語の文字で始まり、その後に文字、数字、_-. @ 記号が続きます'));
    }それ以外 {
      折り返し電話（）;
    }
  }
}

この validator.js ファイルを vue ファイルにインポートします。

'@/common/validator.js' から {loginNameValidator} をインポートします。

複数の外部バリデータをインポートする必要がある場合は、{loginNameValidator,passwordValidator} のように、{} に複数のバリデータを含めます。

ここには小さな穴がありますので、簡単に説明しておきます。

ディレクトリ構造に従って、まず次のステートメントを使用します。

'../../../common/validator.js' から {loginNameValidator} をインポートします。

その結果、「../../../common/validator.js」ファイルが見つからないというコンパイルエラーが発生したため、さまざまなパス表現方法を試しましたが、すべて失敗しました。最後に、@ に変更しましたが、/bulid/webpack.base.conf.js で alias が設定されており、@ が src ディレクトリを表していることが示されているため、動作しました。

カスタムバリデータに戻ると、その形式は次のようになります。

関数 ValidatorFuncName(ルール、値、コールバック)

メソッド名（オプション）。

実際、その完全な形式は次のとおりです。

関数 ValidatorFuncName(ルール、値、コールバック、ソース、オプション)

パラメータの意味は次のとおりです。

ルール: ルールのオブジェクトを指します。メソッドコードに最初の文を追加できます。

console.log(ルール);

ルールパラメータを印刷して、このルールのオブジェクトデータを表示できます。

value: 検証する必要がある属性の値。

callback: 検証の最後にコールバック関数を指します。検証に合格すると、callback() が呼び出されます。検証に失敗した場合には、通常、次の形式が使用されます。

callback(new Error('特定のプロンプト情報'));
または、パラメータ付きのプロンプト:

return callback(new Error(`${rule.field} は小文字の英数字でなければなりません`));

文字列の書式設定は一重引用符で囲まれず、「~」記号で囲まれることに注意してください。

async-validator 公式サイト (https://github.com/yiminghe/async-validator) の方法を使用することもできます。

util.format('%s は小文字の英数字でなければなりません', rule.field),

util ファイルにはフォーマットメソッドが含まれています。この util.ts ファイルは、公式 Web サイトの src/ ディレクトリにあります。これは ts ファイルであり、パブリックメソッドに似ています。

実際には、次のような Error の配列、つまりエラーを返すことができます。

      エラーを定数で表す。
      errors.push(new Error('要件: 英語の文字で始まり、その後に文字、数字、_-. @ 記号が続きます'));
      errors.push(新しいエラー('3444必須: 英語'));
      コールバック(エラー)を返します。

しかし、実際の効果から見ると、フォームには最初の行のプロンプトのみが表示されます。Element のフォームは、複数行のエラー情報の表示をサポートしていないと推測されます。

source: は呼び出し検証用の属性オブジェクトであり、印刷して表示できます。
オプション、追加パラメータ、主に定義済みのメッセージ形式も印刷して表示できます。

より複雑なバリデーターでは、次のようなパラメータを取ることができます。

// 整数範囲の検証 export const intRangeValidator = (min, max) => (rule, value, callback) => {
  var isInRange = (値 >= 最小) && (値 <= 最大);
  定数reg = /^-?\d+$/;
  var isInt = reg.test(値);
  if (isInRange && isInt){
    コールバック() を返します。
  }それ以外{
    return callback(new Error(`${min} から ${max} までの整数が必要です [${min}, ${max}]`));
  }
}

方向：

      'formData.age': [
        {バリデータ: intRangeValidator(1,100)、トリガー: 'blur'}
      ]、

formData.age 属性の値の範囲が 1 から 100 までの整数であることを示します。

カスタムバリデーターは自由に操作できる余地を提供します。通常のマッチング、数値計算、比較などの操作を使用して複雑な検証を実行できるため、より一般的に使用されています。しかし、カスタムバリデーターを使用すると、面倒すぎる場合があります。

カスタムバリデーターは外部ファイルに配置する必要はなく、vue ファイルに配置することもできます。

データ内に配置されますが、戻り値には含まれず、末尾にコンマはありません。

const loginNameValidator = (ルール、値、コールバック) => {
  定数reg = /^[a-zA-Z][\w-.@]*$/;
  if(値 == '' || 値 == 未定義 || 値 == null){
    折り返し電話（）;
  }それ以外 {  
    if (!reg.test(値)){
      callback(new Error('要件: 英語の文字で始まり、その後に文字、数字、_-. @ 記号が続きます'));
    }それ以外 {
      折り返し電話（）;
    }
  }
}

または、ルール内で直接定義します。

          'formData.ログイン名': [
            {必須: true、メッセージ: "ログイン名は空欄にできません"、トリガー: 'blur'}、
            {バリデータ(ルール、値、コールバック){
              定数reg = /^[a-zA-Z][\w-.@]*$/;
              if(値 == '' || 値 == 未定義 || 値 == null){
                折り返し電話（）;
              }それ以外 {  
                if (!reg.test(値)){
                  callback(new Error('要件: 英語の文字で始まり、その後に文字、数字、_-. @ 記号が続きます'));
                }それ以外 {
                  折り返し電話（）;
                }
              }                
            }, 
             トリガー: 'ぼかし'}
          ]、

3.3 タイプ

type の基本的な使用法は次のとおりです。

      'formData.age': [
        {type: 'integer'、メッセージ: "値は整数でなければなりません"、トリガー: 'blur'}、
      ]、

タイプもルール項目です。タイプ要件を満たしていない場合は、エラーメッセージが表示されます。

サポートされているルールの種類は次のとおりです。

文字列、文字列型、これがデフォルトの型です。タイプが指定されていない場合、デフォルトは文字列になります。
数値、数値型。整数と小数を含みます。
整数、整数型。
float は浮動小数点型で、現時点では整数にはならず、小数点が必要です。
ブール値、ブール型、真偽値。
配列、配列型。
オブジェクト、オブジェクト型は配列にできません。
enum、列挙型、そして列挙型を宣言する必要があります。
メソッド、関数（またはメソッド）型。
regexp、正規タイプは有効な正規表現である必要があり、new RegExp を使用して作成できます。
日付、日付型、値は有効な日付値に変換可能である必要があります。
url、url タイプ、値は url 形式に準拠する必要があります。
電子メール、電子メールの種類、メールボックスの形式に準拠します。
hex、16進数形式。 0xFF12 など。
あらゆる、あらゆるタイプ、制限なし。

ここでの URL およびメールタイプは、次のような関連する意味を持つ属性検証に直接使用できます。

          'formData.email': [
            {type: 'email'、メッセージ: "メールアドレスの形式に準拠する必要があります"、トリガー: 'blur'}
          ]、

日付型も便利です。これらの組み込み型を使用すると、カスタム検証を使用せずに日付を処理できます。

数値型 (number、integer、float) およびブール型の場合、入力は文字列であるため、型変換を実行する必要があります。そうしないと、検証が失敗します。これには変換の使用が含まれます。

3.3 データ変換

Transform は、検証を開始する前にデータを処理および検証できるフック関数です。次の例に示すように:

      'formData.age': [
        {
            タイプ: '整数'、
            メッセージ: 「値は整数でなければなりません」
            トリガー: 'ぼかし'、
            transform(値){return parseInt(値);},
        },
      ]、

変換型変換後、formData.age 属性の検証ルールを通常どおり使用できます。それ以外の場合は、常に型検証に失敗します。（実際にはここで問題があり、12ab という形式で値の出力を許可し、parseInt が値 12 を取得します）

型変換の場合、transform にはより簡潔で厳密な式があります。

  'formData.age': [
    {
        タイプ: '整数',
        メッセージ: 「値は整数でなければなりません」
        トリガー: 'ぼかし'、
        変換：数値},
    },
  ]、

数値型への変換を示します。それだけです。 1.2 または 12ab の値は検証に合格しません。

型変換に加えて、transform は次のような他の処理も実行できます。

          'formData.age': [
            {type : 'string',pattern:/1/,message: "値は 1 から 100 までの数値である必要があります",transform(value){return parseInt(value)>=1 && parseInt(value)<=100 ? "1" : "0";},}
          ]、

値に等しい:

          'formData.age': [
            {type : 'string',pattern:/1/,message: "値は 50 である必要があります",transform(value){return value == "50" ? "1" : "0";},}
          ]、

値と等しくない:

      'formData.age': [
        {type : 'string',pattern:/0/,message: "値は 50 にできません",transform(value){return value == "50" ? "1" : "0";},}
      ]、

3.4. 範囲

範囲はルールの属性フィールドではなく、min 属性と max 属性によって反映されます。

タイプが文字列または配列の場合、min と max は長さを示します。

type が数値型 (数値、整数、浮動小数点数) の場合、min と max は値の範囲を示します。のように：

  'formData.age': [
    {
        タイプ: '整数',
        メッセージ: 「値は 1 から 100 までの整数である必要があります」
        最小: 1,
        最大:100、
        トリガー: 'ぼかし',
        変換:数値、
    },
  ]、

この方法では、範囲チェックはルールの組み込みプロパティを直接使用してルール内に記述することができ、intRangeValidator バリデーターと通常のマッチングメソッドを使用する必要はありません。

3.5 列挙値

列挙値型の使用例:

          'formData.idType': [
            {
                タイプ: 'enum'、列挙型: [2,4,6]、メッセージ: `結果が存在しません`、トリガー: ['change'、'blur']、transform(value) {return Number(value) * 2}、
            },
          ]、  
  または：

      'formData.性別': [
        {
            タイプ: 'enum'、列挙型: ['male','female']、メッセージ: `結果が存在しません`、トリガー: ['change', 'blur']、
        },
      ]、

使用に際しては以下のような問題があります。

応答はかなり遅いので、最初の数回の入力では検証が行われません。検証されると、他のすべては正常に動作します。
後者の場合、範囲は文字列のコレクションであり、検証は正常に機能します。前者の場合、つまり範囲が整数の場合、0 もチェックに合格し、すべての文字列もチェックに合格することになり、これはバグです。

したがって、範囲を確認するために文字列列挙値を使用することもできます。

          'formData.age': [
            {
                タイプ: 'enum'、
                列挙型:["1"],
                メッセージ: 「値は 1 から 100 までの数値である必要があります」
                変換(値){
                    if (!isNaN(値)){
                      parseInt(値)>=1 && parseInt(値)<=100 ? "1" : "0" を返します。
                    }それ以外{
                      「0」を返します。
                    }
               }
            },
          ]、

注: この時点では、parseInt 関数は e の前の数字のみを取得し、isNaN はそれらを数値と見なすため、1e3 と 9e811 は検証に合格したと見なされます。やはり通常のルールとの調整が必要そうです。

3.6 規則的なパターン

パターン属性は、次のような正規表現一致検証ルールです。

          'formData.ログイン名': [
            {必須: true、メッセージ: "ログイン名は空にできません"、トリガー: 'blur'}、
            {パターン:/^[a-zA-Z][\w-.@]*$/,
             メッセージ:'要件: 英語の文字で始まり、その後に文字、数字、_-.@ 記号が続きます',
             トリガー: 'ぼかし'}
          ]、

効果は以前の loginNameValidator バリデーターと同じですが、違いは loginNameValidator は再利用でき、通常の検証を維持し、変更する必要がある場合は 1 か所を変更するだけで済むことです。パターンの場合はそうではありません。しかし、パターンを使用すると、カスタム検証を記述する必要性を減らし、ユーザーに選択肢を与えることができます。

パターン属性を使用すると、値が特定の値と等しいかどうかを確認できます。

値に等しい:

{pattern:/120/、メッセージ:'120 である必要があります'、トリガー: 'blur'}

js 正規表現に関しては、まず js 正規表現オンラインテストツールを使用してテストし、期待される効果が得られるかどうかを確認できます。 js 正規表現オンラインテストアドレス: https://c.runoob.com/front-end/854。

3.7. 長さlen

len 属性は、型が文字列または配列の場合、長さを示します。数値型の場合は、その数値が len 属性値であることを意味します。

len 属性が min 属性および max 属性と一緒に出現する場合、len 属性が優先されます。

len 属性は、ID カード番号の長さなど、フォーマットされた文字列を検証するために使用できます。

len は、次のように特定の値と等しいかどうかを確認するためにも使用できます。

  'formData.age': [
    {
        タイプ: '整数',
        メッセージ: 「値は6年前のものでなければなりません」
        長さ: 6,
        トリガー: 'ぼかし',
        変換:数値、
    },
  ]、

3.8 空白

空白は、完全にスペースで構成された文字列を意味します。ルールタイプは文字列である必要があります。ルールが一致すると、アラームが表示されます。のように：

          'formData.email': [
             {空白: true、メッセージ: 'スペースのみ'、トリガー: 'ぼかし'}
          ]、

値がスペースの場合、警告が表示されます。

スペースが検証に干渉しないようにするには、 transform を使用して処理します。

変換(値) { 戻り値.trim();}

3.9、国際化

メッセージは i18n、つまり国際化をサポートしています。vue-i18n を統合する場合、メッセージ属性の使用方法は次のようになります。

メッセージ: () => this.$t('about')

中国語では「About」と表示され、英語では「about」と表示されます。

もちろん、次のような他の関数に置き換えることもできます。

メッセージ: () => this.myMessageHandler(MessageId,paramValues)

4. ルール検証の高度なモード

4.1. 非同期バリデータ

非同期バリデータは、リモートアクセスに使用され、Ajax または Axios を使用してデータを要求し、応答データを検証したり、例外を要求したりします。

ローカルページ検証はシリアル検証です。各フィールドの検証ルールを 1 つずつチェックします。失敗した場合は検証失敗を返します。

リモート検証は非同期検証です。複数のリクエストの応答時間は異なり、応答の順序は予測できません。

非同期検証の役割: フロントエンドとバックエンドは同じ属性フィールドに対して同じ検証ルールを使用でき、検証はバックエンドによって均一に提供されます。しかし、これにより、フロントエンドとバックエンドの通信および一貫性の維持にかかるコストも増加します。

非同期バリデータはまだ使用されていません。以下は公式 Web サイトからの例です。

asyncField1:{asyncValidator: myAsyncValidator}
  myAsyncValidator は validator と同様の位置に配置できます。データ内に配置されていると仮定します。

const myAsyncValidator = (ルール、値、コールバック) => {
      アヤックス({
        URL: 'xx',
        値: 値、
      }).then(関数(データ) {
        折り返し電話（）;
      }, 関数(エラー) {
        コールバック(新しいエラー(error));
      });
    }

Promise 非同期フィールド検証:

 const myAsyncValidator = (ルール、値) => {
      ajaxを返す({
        URL: 'xx',
        値: 値、
      });
    }

違いは、Promise 非同期フィールド検証ではユーザーが独自の .then/.catch 処理ロジックを記述する必要があり、コールバックをサポートしていないことです。

非同期検証には Options プロパティも関係します。

オプション: { first: true },

first は true であり、最初のチェック後に複数の非同期チェックが失敗した場合、他の非同期チェックは処理されないことを示します。

4.2 ディープルール

オブジェクトまたは配列の検証では、各要素 (メンバー) を検証する必要があり、ここでは Deep ルールが使用されます。

ディープルールには、fields と defaultField という 2 つの属性が含まれます。

公式ウェブサイトの例に示すように（慣例の形式に従って若干変更されています）：

オブジェクトの詳細な検査:

ルール:
  住所： [{
    タイプ: 'オブジェクト'、
    必須: true、
    オプション: { first: true },
    フィールド: {
      住所: [{ type: 'string', required: true }],
      都市: [{ タイプ: '文字列', 必須: true }],
      郵便番号: [{ タイプ: '文字列'、必須: true、長さ: 8、メッセージ: '無効な郵便番号' }]、
    },
  }],
  名前: [{ タイプ: '文字列', 必須: true }],
};

配列の詳細な検証:

ルール:
  役割: [{
    タイプ: '配列',
    必須: true、
    長さ: 3,
    フィールド: {
      0: [{ タイプ: '文字列'、必須: true }],
      1: [{ タイプ: '文字列'、必須: true }],
      2: [{ タイプ: '文字列'、必須: true }]、
    },
  }],
};

配列の詳細な検証はばかげているようです。各メンバーで検証ルールを設定する必要があります。動的配列の場合、設定方法がわからないようです。

defaultField 属性を使用すると、フィールド検証ルールを均一に設定できます。このプロパティは、検証属性フィールドまたはフィールドに適用できます。

例えば：

ルール:
  URL: [{
    タイプ: '配列',
    必須: true、
    デフォルトフィールド: { タイプ: 'url' },
  }],
};

オブジェクトの配列の場合、どのように設定すればよいでしょうか?以下の方法が利用可能です:

ルール:
  人物: [{
    タイプ: '配列',
    必須: true、
    デフォルトフィールド:{
        タイプ: 'オブジェクト'、
        必須: true、
        フィールド: {
            住所： [{
                タイプ: 'オブジェクト'、
                必須: true、
                フィールド: {
                    住所: [{ type: 'string', required: true }],
                    都市: [{ タイプ: '文字列', 必須: true }],
                    郵便番号: [{ タイプ: '文字列', 必須: true, 長さ: 8, 
                           メッセージ: '無効な郵便番号' }],
                },
            }],
            名前: [{ タイプ: '文字列', 必須: true }],                  
        }
    }
  }],
};

オブジェクト内の配列、サブオブジェクト内のオブジェクト、少し複雑そうです。

4.3 動的ルールセット

場合によっては、フォームに異なるモードが入力され、異なるルールを適用する必要があります。追加操作と編集操作では、同じページコンポーネントが表示されます。しかし、現時点では、ページ上で検証する必要がある属性フィールドが異なります。どのように設定すればよいでしょうか?

解決策は2つあります。ソリューション 1 は、2 つのルールセットを構成し、異なるモードに応じて切り替えることです。ソリューション 2 は、全体のルールセットを構成し、異なるモードに応じて適切な属性フィールドとルールを抽出し、ルールセットを動的に構築することです。

4.3.1. スイッチング検証ルールセット

検証ルールセットを切り替えます。サンプルコードは次のとおりです。

      // データ部分 // 現在のルールセット ルール:{},
      // モード 1 ルール セット rules1:{
         ...
      },
      // モード 2 ルール セット rules2:{
          ...
      },

      // メソッド部分 // 動的切り替え // ページの初期化 init(obj,data){
        this.prevForm = obj;

        //ページを表示可能に設定します this.visible = true;

        //これを実行します。$nextTick(()=>{
          // 現在のページのすべてのフィールド値をリセットします this.$refs['form'].resetFields();

          if (データ){
            // モード 1
            this.form.patternType = 1;        
          }それ以外{
            // モード 2
            this.form.patternType = 2;
          }        
          // 検証ルールを設定する this.setValidRules(this.form.patternType);
        }
    },
      setValidRules(パターンタイプ){
        if(パターンタイプ == 1){
            this.rules = this.rules1;
        }そうでない場合(パターンタイプ == 2){
            this.rules = this.rules2;
        }
      },

このように、検証ルールセットはさまざまなモードに応じて切り替えられます。ルールを切り替えるときにすぐにルール検証を実行するには、el-form の validate-on-rule-change を false に設定する必要があります。つまり、次のようになります。

<el-form ref="フォーム" :model="フォーム" :rules="ルール" 
         :ルール変更時の検証=false 
         クラス="useredit" ラベル幅="100px" スタイル="行の高さ: 30px;">

4.3.2. 検証ルールセットを動的に構築する

検証ルールセットを動的に構築します。サンプルコードは次のとおりです。

      // データ部分 // 現在のルールセット ルール:{},
      // すべてのルール allRules:{
          'formData.ログイン名': [
            {必須: true、メッセージ: "ログイン名は空欄にできません"、トリガー: 'blur'}、
            {validator:loginNameValidator、トリガー: 'blur'}
          ]、
          'formData.passwd': [
            {必須: true、メッセージ: "パスワードは空欄にできません"、トリガー: 'blur'}、
            {最小: 6、最大: 18、メッセージ: "パスワード 6〜18 桁"、トリガー: 'blur'}
          ]、
          'formData.email': [
             {type: 'email'、message: 'メール形式に準拠する必要があります'、trigger: 'blur'}
          ]、          
          性別ラベル:
            {必須: true、メッセージ: 「性別は空欄にできません」、トリガー: '変更'}、
          ]、
          ユーザータイプラベル: [
            {必須: true、メッセージ: "ユーザー タイプは空にできません"、トリガー: '変更'}、
          ]、
          部門ラベル: [
            {必須: true、メッセージ: 「部門は空にできません」、トリガー: '変更'}、
          ]
      },
          
      // メソッド部分 // 動的切り替え // ページの初期化 init(obj,data){
        this.prevForm = obj;

        //ページを表示可能に設定します this.visible = true;

        //これを実行します。$nextTick(()=>{
          // 現在のページのすべてのフィールド値をリセットします this.$refs['form'].resetFields();

          if (データ){
            // モード 1
            this.form.patternType = 1;        
          }それ以外{
            // モード 2
            this.form.patternType = 2;
          }        
          // 検証ルールを設定する this.setValidRules(this.form.patternType);
        }
    },
      setValidRules(パターンタイプ){
        パターンタイプ == 1 の場合{
          // モード 1
          // 最初にクリアしてから設定します this.rules = {};
          this.rules['性別ラベル'] = this.allRules['性別ラベル'];
          this.rules['userTypeLabel'] = this.allRules['userTypeLabel'];
          this.rules['deptLabel'] = this.allRules['deptLabel'];
          this.rules['formData.email'] = this.allRules['formData.email'];
        } それ以外{
          // モード 2、ログイン名とパスワードの検証が必要 this.rules = {};
          this.rules['formData.loginName'] = this.allRules['formData.loginName'];
          this.rules['formData.passwd'] = this.allRules['formData.passwd'];
          this.rules['性別ラベル'] = this.allRules['性別ラベル'];
          this.rules['userTypeLabel'] = this.allRules['userTypeLabel'];
          this.rules['deptLabel'] = this.allRules['deptLabel'];
          this.rules['formData.email'] = this.allRules['formData.email'];
        }
      },

また、el-form の validate-on-rule-change を false に設定する必要があります。

4.4. 動的テーブルフィールド検証

一部のフォームでは、データ行を追加したり、データ行に直接データを入力して送信したりするなど、編集可能な動的テーブルを使用します。このとき、データ行の各フィールドの入力を検証する必要があります。

選択肢は2つあります。

ソリューション 1 では、上記のサンプルコードに示すように、defaultField of Deep ルールを使用して、オブジェクト配列のフィールド検証を実行します。

解決策 2: el-form-item レベルの rules 属性を使用して、フィールドルールをバインドします。

4.5. 複数フィールドの共同検証

複数フィールドの共同検証の応用シナリオは、テキストの冒頭の問題など、比較的一般的です。異なる ID タイプには異なる検証ルールがあります。たとえば、パスワード検証では、2 つのパスワードが同じである必要があります。たとえば、購入数量は在庫数量を超えてはならず、期間の開始時刻は終了時刻より大きくてはいけません。

重要なスキルは、バリデーターの最初のパラメータールールを使用して 1 つ以上のカスタム属性を追加し、その情報をバリデーターに渡して処理することです。使い方は次のとおりです:

たとえば、「formData.email」フィールドの検証が userType の値に依存するとします。

          'formData.email': [            
             {バリデータ: idFieldWithTypeValidator、トリガー: 'blur'、}
          ]、

最初にバインドする方法はありません:

          'formData.email': [            
             {バリデータ: idFieldWithTypeValidator、トリガー: 'blur'、'userType': this.form.formData.usertype}
          ]、

このように記述すると、ブラウザデバッガーは、resetFields の呼び出しでエラーが発生したことを示すエラーを表示します。

したがって、正しい形式は次のようになります。

      'formData.email': [            
         {バリデータ: idFieldWithTypeValidator、トリガー: 'blur'、}
      ]、

または：

      'formData.email': [            
         {バリデータ: idFieldWithTypeValidator、トリガー: 'blur'、'userType': 0}
      ]、

次に、ページが初期化されるとき、または選択ボックスが変更されたときの変更イベントメソッドで、ルール内の userType 属性の値を動的に設定します。

this.rules['formData.email'][0]['userType'] = this.form.formData.userType;

テスト結果から、$set は動的バインディングには使用できないことがわかります。つまり、次のステートメントは効果がありません。

this.$set(this.allRules['formData.email'][0],'userType',this.form.formData.userType);

さて、これで共同検証 idFieldWithTypeValidator を記述できるようになりました。簡単にするために、データセクションに次のように記述します。

      const idFieldWithTypeValidator = (ルール、値、コールバック) => {
        // ユーザータイプを取得する console.log(rule);
        コールバック() を返します。
      }

これをテストし、次のようにブラウザコンソールにルールの印刷情報を出力します。

{
    "ユーザータイプ": 2,
    "フィールド": "formData.email",
    "fullField": "formData.email",
    "タイプ": "文字列"
}

この時点で、userType はルールパラメータを通じて渡され、共同検証を実行できるようになりました。

  '@/common/validator.js' から {loginNameValidator、phoneNoValidator、idNoValidator、eMailValidator} をインポートします。
  エクスポートデフォルト{
    データ（） {
      // 異なるタイプの ID フィールド検証子 const idFieldWithTypeValidator = (rule, value, callback) =>{
        // ユーザータイプを取得する console.log(rule);
        （ルール.userType == 1）の場合{
          // 携帯電話番号 phoneNoValidator(rule, value, callback);
        }そうでない場合(rule.userType == 2){
          // ID 番号 idNoValidator(rule, value, callback);
        }そうでない場合(rule.userType == 3){
          // メール
          eMailValidator(ルール、値、コールバック);
        }
      }

      戻る {
          ....
      }            
    },
    ...
  }

このうち、phoneNoValidator、idNoValidator、eMailValidator はそれぞれ携帯電話番号検証、ID カード番号検証、メール形式検証であり、validator.js から出力されます。idFieldWithTypeValidator 検証は、userType パラメータの値に応じて、対応する検証タイプ検証を呼び出します。もちろん、idFieldWithTypeValidator のメソッドコードでは、外部バリデーターを呼び出さずに、各バリデーターのコードを移動することもできます。