Vue Element-ui form validation rule implementation

1. Introduction

Element-ui form validation rules allow error prompts to be displayed directly below the form-item without a pop-up box, so it is still very useful.

After I did the form validation on the login page, I thought I already understood the form validation rules. But when I used the form validation rules in depth, I encountered the following problems:

• How to determine whether an attribute value is within a certain range, and this range can be specified arbitrarily?
• How to determine whether an attribute value is a certain value?
• How to perform joint verification of multiple attributes if the verification rule of the current attribute depends on the value of another attribute? For example, on the registration page, the ID types include email address, mobile phone number, and ID card number. If you select different types, the verification rules of the IDValue attribute are different. How to deal with it?
• In the two modes, when entering the same form component, some fields may not use validation rules, that is, the objects of rules will be different. How to handle this situation?

The above questions make me feel almost like a newbie. This forced me to study the validation rules from scratch and consult relevant documents.

This article shares my experience with form validation rules.

2. Entry mode of rule verification

2.1 Sample Code

As an introduction to rule verification, take the login page as an example, the code is as follows:

<template> 
  <div class="login-container">    
    <el-form ref="form" :model="form" :rules="rules" label-width="80px" class="login-form">
      <h2 class="login-title">XX Management System Login</h2>
      <el-form-item label="Username:" prop="username">
        <el-input v-model="form.username"></el-input>
      </el-form-item>
      <el-form-item label="Password:" prop="password">
        <el-input v-model="form.password" type="password"></el-input>
      </el-form-item>
      <el-form-item label="Verification Code:" 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="Click to change" title="Click to change" />
        </div>
      </el-form-item>
      <el-form-item>
        <el-button type="primary" id="login" style="width:160px" @click="submitForm('form')">Login</el-button>
      </el-form-item>
    </el-form>
  </div>  
</template>

<script>
import { mapMutations } from 'vuex'
export default {
  data() {
    return {
      form: {
        username: "",
        password: "",
        verifyCode: "",
      },
      rules:
        username: [
          {required: true, message: "Username cannot be empty", trigger: 'blur'},
        ],
        password: [
          {required: true, message: "The password cannot be empty", trigger: 'blur'},
          {min: 6, max: 30, message: "Password 6-30 characters", trigger: 'blur'}
        ],
        verifyCode:
          {required: true, message: "Verification code cannot be empty", trigger: 'blur'},
        ]
      }      
    };   
  },
  methods: {
    // Submit login submitForm(formName) { 
      let _this = this;     
      // Execute validation this.$refs[formName].validate(valid => {
        // If the verification is passed, it is true; if one fails, it is false
        if (valid) {
          // Pass verification // Login process // ....
        } else {
          // Failed to verify console.log('Verification failed');
          return false;
        }
      });
    },
  }  
}
</script>

2.2, form items

form item, indicating the validation rules to be used:

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

:rules="rules" specifies that the validation rules use the rules object. You can also use other names, such as rules1.

2.3. prop item

prop item, indicating which fields may use validation rules:

      <el-form-item label="Username:" prop="username">
        <el-input v-model="form.username"></el-input>
      </el-form-item>

If the property value specified by the prop item, such as username, also has a corresponding item in rules, it means that the property value executes rule verification. This attribute must be the attribute of the data object bound to the model attribute of the form. In this case, it is form, which is defined in data:

      form: {
        username: "",
        password: "",
        verifyCode: "",
      },

2.4, rules item

The rules item, that is, the validation rule set, is defined in data, and its name must be consistent with the name of the rules object bound to the :rules attribute of form.

      rules:
        username: [
          {required: true, message: "Username cannot be empty", trigger: 'blur'},
        ],
        password: [
          {required: true, message: "The password cannot be empty", trigger: 'blur'},
          {min: 6, max: 30, message: "Password 6-30 characters", trigger: 'blur'}
        ],
        verifyCode:
          {required: true, message: "Verification code cannot be empty", trigger: 'blur'},
        ]
      }      

This is an object, each element is of type: {property name: [rule]}, the property name corresponds to the property value of prop. [rule] is a rule array, each item in the rule array is a validation rule for this attribute.

2.5. Rule Item

The rule item, that is, the element of the rule array, is the key item to be discussed in this article. Here we first analyze the elements of the above rules:

• required: indicates whether a value is required. The value is true/false. If it is true, it means that a value is required. If there is no value, the check fails. If it is false, no value is allowed, but if there is a value, it does not affect the use of other rules.
• message: prompt message, this message will be prompted when the verification fails.
• trigger: trigger mode, the value is blur/change, blue means loss of focus, generally used in input components; change means value change, generally used in selection boxes.
• min: minimum string length.
• max: Maximum length of the string.

With these explanations, it is not difficult to understand the validation rules for each attribute defined in the above rules.

2.6. Rules of Use

this.$refs['form'].validate(valid => {
        // If the verification is passed, it is true; if one fails, it is false
        if (valid) {
          // Pass verification } else {
          // Failed verification}
      });

This validate method requires that all validation rules pass before it is released. Among them, $refs['form'] points to the ref attribute value of form.

2.7. The core of rule verification

The core of rule validation is the async-validator plug-in, official website: https://github.com/yiminghe/async-validator.

Element-UI uses this plug-in and encapsulates it. Official website: https://element.eleme.cn/#/zh-CN/component/form.

Therefore, information from both sides will be helpful.

3. Advanced mode of rule verification

3.1. Nested object attribute names

Sometimes, a prop is not a simple attribute, but a property wrapped in another object. like:

      <el-form-item label="Login Name:" prop="formData.loginName">
        <el-input v-model="form.formData.loginName" :disabled="form.formData.userId != 0"></el-input>
      </el-form-item>

The form object bound to the form's model is in the form of:

        form:{
          // form data field. To facilitate submission to the backend, it is recommended to name it the same as the UserInfo field formData : {
            userId : 0,
            loginName : '',
            passwd : '',
            // ...
          },

          // The current display value of the user type selection box userTypeLabel: "",
          // ...
        },

At this time, the element definition of rules cannot be in the following form:

        formData.loginName: [
          {required: true, message: "Login name cannot be empty", trigger: 'blur'},
        ],

In this way, the compilation will report an error!

The following form should be used:

    'formData.loginName': [
      {required: true, message: "Login name cannot be empty", trigger: 'blur'},
    ],

That is, wrap it in single or double quotes to turn it into a string.

3.2. Custom validator

There is a lot of information about custom validators on the Internet, such as validators for commonly used regular expression checks.

Rule definition method:

          'formData.loginName': [
            {required: true, message: "Login name cannot be empty", trigger: 'blur'},
            {validator:loginNameValidator, trigger: 'blur'}
          ],

Indicates that the 'formData.loginName' attribute uses the loginNameValidator validator. Considering the reuse of code, the custom validator is usually separated into a js file to facilitate the use of other pages or projects.

In the /src/common/ directory, create the validator.js file with the following code:

/* Login name verification */
export function loginNameValidator(rule, value, callback){
  const reg= /^[a-zA-Z][\w-.@]*$/;
  if(value == '' || value == undefined || value == null){
    callback();
  }else {  
    if (!reg.test(value)){
      callback(new Error('Requirement: Start with an English letter, followed by letters, numbers and _-. @ symbols'));
    }else {
      callback();
    }
  }
}

Import this validator.js file in your vue file:

import {loginNameValidator} from '@/common/validator.js'

If you need to import multiple external validators, include multiple in {}, such as {loginNameValidator,passwordValidator}.

There is a small pit here, let me just mention it briefly.

According to the directory structure, I first use the following statement:

import {loginNameValidator} from '../../../common/validator.js'

As a result, a compilation error occurred, saying that the '../../../common/validator.js' file could not be found, so various path representation methods were tried, but all failed. Finally, I changed to @ and it worked because alias was configured in /bulid/webpack.base.conf.js, indicating that @ represents the src directory.

Back to the custom validator, its form is:

function ValidatorFuncName(rule, value, callback)

Method name, optional.

In fact, its full form is:

function ValidatorFuncName(rule, value, callback, source, options)

The parameters have the following meanings:

rule: points to the object of the rule. You can add the first sentence in the method code:

console.log(rule);

You can print out the rule parameters to see the object data of this rule.

value: The value of the attribute, which needs to be verified.

callback: points to the callback function at the end of the verification. If the verification passes, callback() is called. If it fails, the following form is generally used:

callback(new Error('specific prompt information'));
Or a prompt with parameters:

return callback(new Error(`${rule.field} must be lowercase alphanumeric characters`));

Note that string formatting is not enclosed in single quotes, but in "~" symbols.

You can also use the method of async-validator official website (https://github.com/yiminghe/async-validator):

util.format('%s must be lowercase alphanumeric characters', rule.field),

The util file contains the format method. This util.ts file is in the src/directory of the official website. This is a ts file, which can be similar to a public method.

In fact, you can return an array of Error, that is, errors, such as:

      const errors = [];
      errors.push(new Error('Requirement: start with an English letter, followed by letters, numbers and _-. @ symbols'));
      errors.push(new Error('3444Required: English'));
      return callback(errors);

But from the actual effect, the form only shows the prompt for the first line. It is estimated that Element's form does not support displaying multiple lines of error information.

• source: is the attribute object for calling verification, which can be printed out for viewing.
• options, additional parameters, mainly predefined message formats, can also be printed out for viewing.

More complex validators can take parameters, such as:

// Integer range validation export const intRangeValidator = (min, max) => (rule, value, callback) => {
  var isInRange = (value >= min) && (value <= max);
  const reg = /^-?\d+$/;
  var isInt = reg.test(value);
  if (isInRange && isInt){
    return callback();
  }else{
    return callback(new Error(`Requires an integer between ${min} and ${max} [${min}, ${max}]`));
  }
}

Directions:

      'formData.age': [
        {validator: intRangeValidator(1,100), trigger: 'blur'}
      ],  

Indicates that the value range of the formData.age attribute is an integer from 1 to 100.

Custom validators provide room for free play. They can use regular matching, numerical calculations, comparisons and other operations to perform complex verification, so they are more commonly used. But using a custom validator can sometimes be too cumbersome.

Custom validators do not have to be placed in external files, they can also be placed in vue files.

Placed in data but not included in return, with no trailing comma.

const loginNameValidator = (rule, value, callback) => {
  const reg= /^[a-zA-Z][\w-.@]*$/;
  if(value == '' || value == undefined || value == null){
    callback();
  }else {  
    if (!reg.test(value)){
      callback(new Error('Requirement: Start with an English letter, followed by letters, numbers and _-. @ symbols'));
    }else {
      callback();
    }
  }
}

Or define it directly in the rule:

          'formData.loginName': [
            {required: true, message: "Login name cannot be empty", trigger: 'blur'},
            {validator(rule, value, callback){
              const reg= /^[a-zA-Z][\w-.@]*$/;
              if(value == '' || value == undefined || value == null){
                callback();
              }else {  
                if (!reg.test(value)){
                  callback(new Error('Requirement: Start with an English letter, followed by letters, numbers and _-. @ symbols'));
                }else {
                  callback();
                }
              }                
            }, 
             trigger: 'blur'}
          ],

3.3 Type

The basic usage of type type is as follows:

      'formData.age': [
        {type: 'integer',message: "Value must be an integer",trigger: 'blur'},
      ],

Type is also a rule item. If it does not meet the type requirements, an error message will be prompted.

The supported rule types are as follows:

• string, string type, this is the default type. If type is not specified, the default is string.
• number, numeric type. Includes integers and decimals.
• integer, integer type.
• float, floating point type, cannot be an integer at this time and must have a decimal point.
• boolean, Boolean type, true/false value.
• array, array type.
• object, object type, cannot be an array.
• enum, enumeration type, and then you need to declare the enumeration type.
• method, function (or method) type.
• regexp, regular type, must be a valid regular expression and can be created using new RegExp.
• date, date type, the value must be convertible to a valid date value.
• url, url type, the value must conform to the url format.
• email, email type, conforms to the mailbox format.
• hex, hexadecimal format. Such as 0xFF12.
• any, any type, no restrictions.

The url and email types here can be directly used for attribute verification with related meanings, such as:

          'formData.email': [
            {type: 'email', message: "Must conform to the email address format", trigger: 'blur'}
          ],

Date types are also useful. These built-in types allow us to handle them without having to use custom validators.

For numeric types (number, integer, float) and boolean types, since the input is a string, type conversion must be performed, otherwise the verification will fail. This involves the usage of transform.

3.3 Data Transformation

Transform is a hook function that can process and verify data before starting verification. As shown in the following example:

      'formData.age': [
        {
            type: 'integer',
            message: "Value must be an integer",
            trigger: 'blur',
            transform(value){return parseInt(value);},
        },
      ],

After the transform type conversion, the validation rules of the formData.age attribute can be used normally, otherwise it will always fail the type validation. (There is actually a problem here, such as allowing the output of values ​​in the form of 12ab, and parseInt gets the value 12)

For type conversion, transform has a more concise and strict expression:

  'formData.age': [
    {
        type:'integer',
        message: "Value must be an integer",
        trigger: 'blur',
        transform：Number},
    },
  ],

Indicates conversion to a numeric type, and that's it. Values ​​of 1.2 or 12ab will not pass verification.

In addition to type conversion, transform can also perform other processing, such as:

          'formData.age': [
            {type : 'string',pattern:/1/,message: "The value must be a number between 1 and 100",transform(value){return parseInt(value)>=1 && parseInt(value)<=100 ? "1" : "0";},}
          ],  

Is equal to a value:

          'formData.age': [
            {type : 'string',pattern:/1/,message: "The value must be 50",transform(value){return value == "50" ? "1" : "0";},}
          ],  

Not equal to a value:

      'formData.age': [
        {type : 'string',pattern:/0/,message: "The value cannot be 50",transform(value){return value == "50" ? "1" : "0";},}
      ],  

3.4. Range

Range is not an attribute field of the rule, it is reflected by the min and max attributes.

If type is string or array, min and max indicate the length.

If type is a numeric type (number, integer, float), min and max indicate the range of values. like:

  'formData.age': [
    {
        type:'integer',
        message: "The value must be an integer between 1 and 100",
        min: 1,
        max:100,
        trigger:'blur',
        transform:Number,
    },
  ],

In this way, range checking can directly use the built-in properties of the rule and be described in the rule, without the need to use the intRangeValidator validator and regular matching method.

3.5 Enumeration Values

Example usage of enumeration value types:

          'formData.idType': [
            {
                type: 'enum', enum: [2,4,6], message: `Result does not exist`, trigger: ['change', 'blur'], transform(value) {return Number(value) * 2},
            },
          ],  
  or:

      'formData.gender': [
        {
            type: 'enum', enum: ['male','female'], message: `Result does not exist`, trigger: ['change', 'blur'],
        },
      ],  

There are the following problems with use:

• The response is rather slow, meaning that the first few times you input, there is no verification. Once it is verified, everything else works fine.
• For the latter case, where the range is a collection of strings, validation works fine. In the former case, that is, the range is an integer, 0 also passes the check, causing any string to pass the check as well, which is a bug.

Therefore, you can also use string enumeration values ​​to verify the range:

          'formData.age': [
            {
                type : 'enum',
                enum:["1"],
                message: "The value must be a number between 1 and 100",
                transform(value){
                    if (!isNaN(value)){
                      return parseInt(value)>=1 && parseInt(value)<=100 ? "1" : "0";
                    }else{
                      return "0";
                    }
               }
            },
          ],  

Note: At this time, 1e3 and 9e811 are considered to have passed the verification because the parseInt function only takes the digits before e, and isNaN considers them to be numbers. It seems that it still needs to be coordinated with regular rules.

3.6 Regular Pattern

The pattern attribute is the regular expression matching verification rule, such as:

          'formData.loginName': [
            {required: true, message: "Login name cannot be empty", trigger: 'blur'},
            {pattern:/^[a-zA-Z][\w-.@]*$/,
             message:'Requirements: Start with an English letter, followed by letters, numbers and _-.@ symbols',
             trigger: 'blur'}
          ],

The effect is the same as the previous loginNameValidator validator, the difference is that loginNameValidator can be reused, maintaining a regular validation, and if you need to modify it, you only need to change one place. This is not the case with pattern. But using pattern can reduce the need to write custom validators and give users a choice.

Using the pattern attribute, you can check whether a value is equal to a certain value.

Is equal to a value:

{pattern:/120/,message:'Must be 120',trigger: 'blur'}

Regarding js regular expressions, you can first test them with the js regular expression online testing tool to check whether they achieve the expected effect. js regular expression online test address: https://c.runoob.com/front-end/854.

3.7. Length len

The len attribute, if the type is string or array, indicates the length. If it is a numeric type, it means that the numeric value is the len attribute value.

When the len attribute appears together with the min and max attributes, the len attribute has a higher priority.

The len attribute can be used to verify the formatted string, such as the length of an ID card number.

len can also be used to check if it is equal to a certain value, such as:

  'formData.age': [
    {
        type:'integer',
        message: "The value must be 6 years old",
        len: 6,
        trigger:'blur',
        transform:Number,
    },
  ],

3.8 Whitespace

Blank means a string consisting entirely of spaces. The rule type must be string. If the rule is matched, an alarm will be displayed. like:

          'formData.email': [
             {whitespace: true, message: 'Only spaces', trigger: 'blur'}
          ],

If the value is a space, a warning will be prompted.

If you don't want spaces to interfere with validation, you can use transform to handle it:

transform(value) { return value.trim();}

3.9、i18n

Message supports i18n, i.e. internationalization. If you integrate vue-i18n, the usage of the message attribute is as follows:

message: () => this.$t('about') 

The Chinese language displays “About”, and the English language displays “about”.

Of course, you can also replace it with any other function, such as:

message: () => this.myMessageHandler(MessageId,paramValues)

4. Advanced mode of rule verification

4.1. AsyncValidator

The asynchronous validator is used for remote access, using ajax or axios to request data, verify the response data or prompt for exceptions.

Local page verification is a serial verification. It checks the verification rules of each field one by one. If it fails, it returns verification failure.

Remote verification is asynchronous verification. Multiple requests have different response times, and the order of responses cannot be predicted.

The role of asynchronous validation: the front-end and back-end can use the same validation rules for the same attribute fields, and the validation is uniformly provided by the back-end. But this also increases the cost of front-end and back-end communication and consistency maintenance.

The asynchronous validator is not used yet, here is the example from the official website:

asyncField1:{asyncValidator: myAsyncValidator}
  myAsyncValidator can be placed in a similar position to validator. Assume it is placed in data.

const myAsyncValidator = (rule, value, callback) => {
      ajax({
        url: 'xx',
        value: value,
      }).then(function(data) {
        callback();
      }, function(error) {
        callback(new Error(error));
      });
    }

Promise asynchronous field verification:

 const myAsyncValidator = (rule, value) => {
      return ajax({
        url: 'xx',
        value: value,
      });
    }

The difference is that Promise asynchronous field verification requires users to write their own .then/.catch processing logic and does not support callbacks.

Asynchronous verification also involves the Options property.

options: { first: true },

first is true, indicating that if multiple asynchronous checks fail after the first check, other asynchronous checks will not be processed.

4.2 Deep rules

For the verification of an object or an array, each element (member) needs to be verified, and Deep rules are used here.

Deep rules involve two attributes: fields and defaultField.

As shown in the official website example (slightly modified according to the customary form):

Deep inspection of the object:

rules:
  address: [{
    type: 'object',
    required: true,
    options: { first: true },
    fields: {
      street: [{ type: 'string', required: true }],
      city: [{ type: 'string', required: true }],
      zip: [{ type: 'string', required: true, len: 8, message: 'invalid zip' }],
    },
  }],
  name: [{ type: 'string', required: true }],
};

Deep validation of arrays:

rules:
  roles: [{
    type: 'array',
    required: true,
    len: 3,
    fields: {
      0: [{ type: 'string', required: true }],
      1: [{ type: 'string', required: true }],
      2: [{ type: 'string', required: true }],
    },
  }],
};

The deep validation of arrays seems silly. Each member needs to set validation rules. For dynamic arrays, it seems that I don’t know how to set them.

The defaultField attribute enables us to uniformly set field validation rules. This property can be applied to validation attribute fields or to fields.

For example:

rules:
  urls: [{
    type: 'array',
    required: true,
    defaultField: { type: 'url' },
  }],
};

If it is an array of objects, how to set it? The following methods are available:

rules:
  persons: [{
    type: 'array',
    required: true,
    defaultField:{
        type: 'object',
        required: true,
        fields: {
            address: [{
                type: 'object',
                required: true,
                fields: {
                    street: [{ type: 'string', required: true }],
                    city: [{ type: 'string', required: true }],
                    zip: [{ type: 'string', required: true, len: 8, 
                           message: 'invalid zip' }],
                },
            }],
            name: [{ type: 'string', required: true }],                  
        }
    }
  }],
};

Arrays within objects, objects within sub-objects, it seems a bit complicated.

4.3 Dynamic Rule Set

Sometimes different modes enter the form and different rules need to be applied. For add and edit operations, the same page component is displayed. But the attribute fields that need to be verified on the page are different at this time. How to set them?

There are two solutions. Solution 1 is to configure two sets of rule sets and switch them according to different modes; Solution 2 is to configure the total rule set, extract appropriate attribute fields and rules according to different modes, and dynamically build the rule set.

4.3.1. Switching verification rule set

Switch the validation rule set. The sample code is as follows:

      // data part // current ruleset rules:{},
      // Mode 1 rules set rules1:{
         ...
      },
      // Mode 2 rules set rules2:{
          ...
      },

      // methods part // dynamic switching // page initialization init(obj,data){
        this.prevForm = obj;

        //Set the page to be visible this.visible = true;

        //Execute this.$nextTick(()=>{
          // Reset all field values ​​of the current page this.$refs['form'].resetFields();

          if (data){
            // Mode 1
            this.form.patternType = 1;        
          }else{
            // Mode 2
            this.form.patternType = 2;
          }        
          // Set validation rules this.setValidRules(this.form.patternType);
        }
    },
      setValidRules(patternType){
        if(patternType == 1){
            this.rules = this.rules1;
        }else if(patternType == 2){
            this.rules = this.rules2;
        }
      },

In this way, the verification rule set is switched according to different modes. In order to perform rule validation immediately when switching rules, you need to set el-form's validate-on-rule-change to false, that is:

<el-form ref="form" :model="form" :rules="rules" 
         :validate-on-rule-change=false 
         class="useredit" label-width="100px" style="line-height: 30px;">

4.3.2. Dynamically build validation rule sets

Dynamically build a validation rule set. The sample code is as follows:

      // data part // current ruleset rules:{},
      // All Rules allRules:{
          'formData.loginName': [
            {required: true, message: "Login name cannot be empty", trigger: 'blur'},
            {validator:loginNameValidator, trigger: 'blur'}
          ],
          'formData.passwd': [
            {required: true, message: "The password cannot be empty", trigger: 'blur'},
            {min: 6, max: 18, message: "Password 6-18 digits", trigger: 'blur'}
          ],
          'formData.email': [
             {type: 'email', message: 'Needs to conform to email format', trigger: 'blur'}
          ],          
          genderLabel:
            {required: true, message: "Gender cannot be empty", trigger: 'change'},
          ],
          userTypeLabel: [
            {required: true, message: "User type cannot be empty", trigger: 'change'},
          ],
          deptLabel: [
            {required: true, message: "Department cannot be empty", trigger: 'change'},
          ]
      },
          
      // methods part // dynamic switching // page initialization init(obj,data){
        this.prevForm = obj;

        //Set the page to be visible this.visible = true;

        //Execute this.$nextTick(()=>{
          // Reset all field values ​​of the current page this.$refs['form'].resetFields();

          if (data){
            // Mode 1
            this.form.patternType = 1;        
          }else{
            // Mode 2
            this.form.patternType = 2;
          }        
          // Set validation rules this.setValidRules(this.form.patternType);
        }
    },
      setValidRules(patternType){
        if (patternType == 1){
          // Mode 1
          // Clear first, then set this.rules = {};
          this.rules['genderLabel'] = this.allRules['genderLabel'];
          this.rules['userTypeLabel'] = this.allRules['userTypeLabel'];
          this.rules['deptLabel'] = this.allRules['deptLabel'];
          this.rules['formData.email'] = this.allRules['formData.email'];
        } else{
          // Mode 2, login name and password verification required this.rules = {};
          this.rules['formData.loginName'] = this.allRules['formData.loginName'];
          this.rules['formData.passwd'] = this.allRules['formData.passwd'];
          this.rules['genderLabel'] = this.allRules['genderLabel'];
          this.rules['userTypeLabel'] = this.allRules['userTypeLabel'];
          this.rules['deptLabel'] = this.allRules['deptLabel'];
          this.rules['formData.email'] = this.allRules['formData.email'];
        }
      },

You also need to set validate-on-rule-change of el-form to false.

4.4. Dynamic table field verification

Some forms use editable dynamic tables, such as adding a data row, directly entering data in the data row, and then submitting it. At this time, you need to verify the input of each field in the data row.

There are 2 options.

Solution 1 uses the defaultField of Deep rules to perform field validation on the object array, as shown in the sample code above.

Solution 2: Use the rules attribute at the el-form-item level to bind the field rules.

4.5. Multi-field joint verification

The application scenarios of multi-field joint verification are relatively common, such as the problem of the beginning of the text. Different ID types have different verification rules; such as password verification, the two passwords must be the same; such as the purchase quantity cannot exceed the inventory quantity, the start time of the time period must not be greater than the end time, and so on.

The key skill is to use the first parameter rule of the validator to add one or more custom attributes and pass the information to the validator for processing. Here’s how to use it:

As an example, suppose the validation of the 'formData.email' field depends on the value of userType.

          'formData.email': [            
             {validator : idFieldWithTypeValidator, trigger: 'blur',}
          ],

There is no way to initially bind:

          'formData.email': [            
             {validator : idFieldWithTypeValidator, trigger: 'blur', 'userType': this.form.formData.usertype}
          ],

When written like this, the browser debugger displays an error, indicating that an error occurred in calling resetFields.

Therefore, the correct form is:

      'formData.email': [            
         {validator : idFieldWithTypeValidator, trigger: 'blur',}
      ],

or:

      'formData.email': [            
         {validator : idFieldWithTypeValidator, trigger: 'blur', 'userType': 0}
      ],

Then, when the page is initialized, or in the chage event method when the selection box is changed, dynamically set the value of the userType attribute in the rule:

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

The test results show that $set cannot be used for dynamic binding, that is, the following statements have no effect:

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

OK, now we can write a joint validator idFieldWithTypeValidator. For simplicity, write in the data section:

      const idFieldWithTypeValidator = (rule, value, callback) => {
        // Get user type console.log(rule);
        return callback();
      }

Test it and output the print information of rule in the browser console as follows:

{
    "userType": 2,
    "field": "formData.email",
    "fullField": "formData.email",
    "type": "string"
}

At this point, userType has been passed in through the rule parameter, and now joint verification can be performed.

  import {loginNameValidator,phoneNoValidator,idNoValidator,eMailValidator} from '@/common/validator.js'
  export default {
    data() {
      // ID field validator for different types const idFieldWithTypeValidator = (rule, value, callback) =>{
        // Get user type console.log(rule);
        if (rule.userType == 1){
          // Mobile phone number phoneNoValidator(rule, value, callback);
        }else if(rule.userType == 2){
          // ID number idNoValidator(rule, value, callback);
        }else if(rule.userType == 3){
          // email
          eMailValidator(rule, value, callback);
        }
      }

      return {
          ....
      }            
    },
    ...
  }

Among them, phoneNoValidator, idNoValidator, and eMailValidator are mobile phone number validators, ID card number validators, and email format validators respectively, which are output from validator.js. The idFieldWithTypeValidator validator calls the corresponding validator type validators according to the value of the userType parameter. Of course, in the method code of idFieldWithTypeValidator, you can also move the code of each validator over without calling the external validator.

5. References

In addition to the official website information, this article also refers to the following articles:

[1] A brief analysis of the async-validator source code, https://zhuanlan.zhihu.com/p/32306570?edition=yidianzixun&utm_source=yidianzixun&yidian_docid=0I5IikUl.

[2] Basic elements of Element form validation in Vue, https://www.php.cn/js-tutorial-406545.html.

[3] Element-ui form validation rules configuration, https://www.cnblogs.com/loveyt/archive/2020/07/11/13282518.html.

[4] Element Ui usage tips - detailed description of Form validation rules, https://www.cnblogs.com/xyyt/p/13366812.html

This is the end of this article about the implementation of Vue Element-ui form validation rules. For more relevant Element form validation rules, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!