Implementierung der Validierungsregel für Vue Element-ui-Formulare

1. Einleitung

Die Validierungsregeln für Element-UI-Formulare ermöglichen die Anzeige von Fehleraufforderungen direkt unter dem Formularelement ohne Popup-Fenster, sodass dies immer noch sehr nützlich ist.

Nachdem ich die Formularvalidierung auf der Anmeldeseite durchgeführt hatte, dachte ich, ich hätte die Regeln zur Formularvalidierung bereits verstanden. Bei eingehender Anwendung der Formularvalidierungsregeln traten jedoch die folgenden Probleme auf:

• Wie kann festgestellt werden, ob ein Attributwert innerhalb eines bestimmten Bereichs liegt, und dieser Bereich kann beliebig angegeben werden?
• Wie kann ermittelt werden, ob ein Attributwert ein bestimmter Wert ist?
• Wie führe ich eine gemeinsame Überprüfung mehrerer Attribute durch, wenn die Überprüfungsregel des aktuellen Attributs vom Wert eines anderen Attributs abhängt? Auf der Registrierungsseite umfassen die ID-Typen beispielsweise E-Mail-Adresse, Mobiltelefonnummer und Personalausweisnummer. Wenn Sie unterschiedliche Typen auswählen, sind die Überprüfungsregeln des IDValue-Attributs unterschiedlich. Wie gehe ich damit um?
• Wenn in den beiden Modi dieselbe Formularkomponente eingegeben wird, verwenden einige Felder möglicherweise keine Validierungsregeln, d. h. die Regelobjekte sind unterschiedlich. Wie geht man mit dieser Situation um?

Angesichts der obigen Fragen fühle ich mich fast wie ein Neuling. Dies zwang mich dazu, die Validierungsregeln von Grund auf zu studieren und relevante Dokumente zu konsultieren.

In diesem Artikel teile ich meine Erfahrungen mit Formularvalidierungsregeln.

2. Eingabemodus der Regelüberprüfung

2.1 Beispielcode

Als Einführung in die Regelüberprüfung nehmen wir als Beispiel die Anmeldeseite. Der Code lautet wie folgt:

<Vorlage> 
  <div Klasse="Login-Container">    
    <el-form ref="form" :model="form" :rules="Regeln" label-width="80px" class="login-form">
      <h2 class="login-title">Anmeldung zum XX-Managementsystem</h2>
      <el-form-item label="Benutzername:" prop="Benutzername">
        <el-input v-model="form.Benutzername"></el-input>
      </el-form-item>
      <el-form-item label="Passwort:" prop="Passwort">
        <el-input v-model="form.password" type="password"></el-input>
      </el-form-item>
      <el-form-item label="Bestätigungscode:" prop="verifyCode">
        <el-input v-model="form.verifyCode"></el-input>
        <div Klasse="divVerifyCodeImg" @click="getVerifyCode(true)">
          <img id="verifyCodeImg" style="height:40px; width: 100px; cursor: pointer;" alt="Zum Ändern klicken" title="Zum Ändern klicken" />
        </div>
      </el-form-item>
      <el-form-item>
        <el-button type="primary" id="login" style="width:160px" @click="submitForm('form')">Anmelden</el-button>
      </el-form-item>
    </el-form>
  </div>  
</Vorlage>

<Skript>
importiere { mapMutations } von 'vuex'
Standard exportieren {
  Daten() {
    zurückkehren {
      bilden: {
        Benutzername: "",
        Passwort: "",
        Prüfcode: "",
      },
      Regeln:
        Benutzername: [
          {erforderlich: true, Nachricht: „Benutzername darf nicht leer sein“, Auslöser: ‚blur‘},
        ],
        Passwort: [
          {erforderlich: true, Meldung: „Das Passwort darf nicht leer sein“, Auslöser: ‚blur‘},
          {min: 6, max: 30, Nachricht: „Passwort 6-30 Zeichen“, Auslöser: ‚blur‘}
        ],
        Prüfcode:
          {erforderlich: true, Meldung: „Verifizierungscode darf nicht leer sein“, Auslöser: ‚blur‘},
        ]
      }      
    };   
  },
  Methoden: {
    // Anmeldung absenden submitForm(formName) { 
      lass _this = dies;     
      // Validierung ausführen this.$refs[formName].validate(valid => {
        // Wenn die Überprüfung erfolgreich war, ist es wahr, wenn sie fehlschlägt, ist es falsch
        if (gültig) {
          // Überprüfung bestehen // Anmeldevorgang // ....
        } anders {
          // Fehler beim Überprüfen console.log('Überprüfung fehlgeschlagen');
          gibt false zurück;
        }
      });
    },
  }  
}
</Skript>

2.2, Formularelemente

Formularelement, das die zu verwendenden Validierungsregeln angibt:

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

:rules="rules" gibt an, dass die Validierungsregeln das Regelobjekt verwenden. Sie können auch andere Namen verwenden, z. B. rules1.

2.3. Requisitenartikel

Prop-Element, das angibt, welche Felder Validierungsregeln verwenden können:

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

Wenn der durch das Prop-Element angegebene Eigenschaftswert, z. B. der Benutzername, auch ein entsprechendes Element in den Regeln hat, bedeutet dies, dass der Eigenschaftswert eine Regelüberprüfung ausführt. Dieses Attribut muss das Attribut des Datenobjekts sein, das an das Modellattribut des Formulars gebunden ist. In diesem Fall ist es das Formular, das in den Daten definiert ist:

      bilden: {
        Benutzername: "",
        Passwort: "",
        Prüfcode: "",
      },

2.4, Regelelement

Das Regelelement, d. h. der Validierungsregelsatz, wird in den Daten definiert und sein Name muss mit dem Namen des Regelobjekts übereinstimmen, das an das :rules-Attribut des Formulars gebunden ist.

      Regeln:
        Benutzername: [
          {erforderlich: true, Nachricht: „Benutzername darf nicht leer sein“, Auslöser: ‚blur‘},
        ],
        Passwort: [
          {erforderlich: true, Meldung: „Das Passwort darf nicht leer sein“, Auslöser: ‚blur‘},
          {min: 6, max: 30, Nachricht: „Passwort 6-30 Zeichen“, Auslöser: ‚blur‘}
        ],
        Prüfcode:
          {erforderlich: true, Meldung: „Verifizierungscode darf nicht leer sein“, Auslöser: ‚blur‘},
        ]
      }      

Dies ist ein Objekt, jedes Element ist vom Typ: {Eigenschaftsname: [Regel]}, der Eigenschaftsname entspricht dem Eigenschaftswert der Eigenschaft. [Regel] ist ein Regel-Array. Jedes Element im Regel-Array ist eine Validierungsregel für dieses Attribut.

2.5. Regelelement

Das Regelelement, also das Element des Regel-Arrays, ist das zentrale Element, das in diesem Artikel behandelt wird. Hier analysieren wir zunächst die Elemente der obigen Regeln:

• erforderlich: Gibt an, ob ein Wert erforderlich ist. Der Wert ist wahr/falsch. Wenn wahr, bedeutet dies, dass ein Wert erforderlich ist. Wenn kein Wert vorhanden ist, schlägt die Prüfung fehl. Wenn falsch, ist kein Wert zulässig, aber wenn ein Wert vorhanden ist, hat dies keine Auswirkungen auf die Verwendung anderer Regeln.
• Nachricht: Eingabeaufforderungsnachricht. Diese Nachricht wird angezeigt, wenn die Überprüfung fehlschlägt.
• Auslöser: Auslösemodus, der Wert ist Unschärfe/Änderung, Blau bedeutet Fokusverlust, wird im Allgemeinen in Eingabekomponenten verwendet; Änderung bedeutet Wertänderung, wird im Allgemeinen in Auswahlfeldern verwendet.
• min: minimale Zeichenfolgenlänge.
• max: Maximale Länge der Zeichenfolge.

Mit diesen Erklärungen ist es nicht schwer, die Validierungsregeln für jedes in den obigen Regeln definierte Attribut zu verstehen.

2.6. Nutzungsregeln

dies.$refs['form'].validate(valid => {
        // Wenn die Überprüfung erfolgreich war, ist es wahr, wenn sie fehlschlägt, ist es falsch
        if (gültig) {
          // Überprüfung bestehen } else {
          // Überprüfung fehlgeschlagen}
      });

Diese Validierungsmethode erfordert, dass alle Validierungsregeln erfüllt werden, bevor sie freigegeben wird. Unter diesen verweist $refs['form'] auf den Ref-Attributwert des Formulars.

2.7. Der Kern der Regelüberprüfung

Der Kern der Regelvalidierung ist das Plug-in „async-validator“, offizielle Website: https://github.com/yiminghe/async-validator.

Element-UI verwendet dieses Plug-in und kapselt es. Offizielle Website: https://element.eleme.cn/#/zh-CN/component/form.

Daher sind Informationen von beiden Seiten hilfreich.

3. Erweiterter Modus der Regelüberprüfung

3.1. Verschachtelte Objektattributnamen

Manchmal ist eine Requisite kein einfaches Attribut, sondern eine in ein anderes Objekt eingebettete Eigenschaft. wie:

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

Das an das Modell des Formulars gebundene Formularobjekt hat die folgende Form:

        bilden:{
          // Formulardatenfeld. Um die Übermittlung an das Backend zu erleichtern, wird empfohlen, es genauso zu benennen wie das UserInfo-Feld formData : {
            Benutzer-ID: 0,
            Anmeldename: '',
            Passwort: '',
            // ...
          },

          // Der aktuelle Anzeigewert des Benutzertyp-Auswahlfelds userTypeLabel: "",
          // ...
        },

Derzeit kann die Elementdefinition von Regeln nicht die folgende Form haben:

        formData.loginName: [
          {erforderlich: true, Meldung: „Anmeldename darf nicht leer sein“, Auslöser: ‚blur‘},
        ],

In diesem Fall wird bei der Kompilierung ein Fehler auftreten!

Es ist folgendes Formular zu verwenden:

    'formData.loginName': [
      {erforderlich: true, Meldung: „Anmeldename darf nicht leer sein“, Auslöser: ‚blur‘},
    ],

Das heißt, setzen Sie es in einfache oder doppelte Anführungszeichen, um es in eine Zeichenfolge umzuwandeln.

3.2. Benutzerdefinierter Validator

Im Internet gibt es zahlreiche Informationen zu benutzerdefinierten Validatoren, beispielsweise zu Validatoren für häufig verwendete Prüfungen regulärer Ausdrücke.

Methode zur Regeldefinition:

          'formData.loginName': [
            {erforderlich: true, Meldung: „Anmeldename darf nicht leer sein“, Auslöser: ‚blur‘},
            {validator:loginNameValidator, Auslöser: "unscharf"}
          ],

Gibt an, dass das Attribut „formData.loginName“ den Validator „loginNameValidator“ verwendet. Im Hinblick auf die Wiederverwendung von Code wird der benutzerdefinierte Validator normalerweise in eine JS-Datei ausgelagert, um die Verwendung auf anderen Seiten oder in Projekten zu erleichtern.

Erstellen Sie im Verzeichnis /src/common/ die Datei validator.js mit dem folgenden Code:

/* Anmeldenamenüberprüfung */
Exportfunktion loginNameValidator (Regel, Wert, Rückruf) {
  const reg= /^[a-zA-Z][\w-.@]*$/;
  wenn(Wert == '' || Wert == undefiniert || Wert == null){
    Rückruf();
  }anders {  
    wenn (!reg.test(Wert)){
      callback(new Error('Anforderung: Beginnen Sie mit einem englischen Buchstaben, gefolgt von Buchstaben, Zahlen und _-. @-Symbolen'));
    }anders {
      Rückruf();
    }
  }
}

Importieren Sie diese Datei validator.js in Ihre Vue-Datei:

importiere {loginNameValidator} aus '@/common/validator.js'

Wenn Sie mehrere externe Validierer importieren müssen, schließen Sie mehrere in {} ein, z. B. {loginNameValidator,passwordValidator}.

Hier gibt es eine kleine Grube, ich möchte sie nur kurz erwähnen.

Entsprechend der Verzeichnisstruktur verwende ich zunächst folgende Anweisung:

importiere {loginNameValidator} aus '../../../common/validator.js'

Als Ergebnis trat ein Kompilierungsfehler auf, der besagte, dass die Datei „../../../common/validator.js“ nicht gefunden werden konnte. Daher wurden verschiedene Methoden zur Pfaddarstellung ausprobiert, die jedoch alle fehlschlugen. Schließlich habe ich es zu @ geändert und es hat funktioniert, weil der Alias ​​in /bulid/webpack.base.conf.js konfiguriert war, was darauf hinweist, dass @ das src-Verzeichnis darstellt.

Zurück zum benutzerdefinierten Validator. Seine Form ist:

Funktion ValidatorFuncName(Regel, Wert, Rückruf)

Methodenname, optional.

Die vollständige Form lautet:

Funktion ValidatorFuncName (Regel, Wert, Rückruf, Quelle, Optionen)

Die Parameter haben folgende Bedeutung:

rule: zeigt auf das Objekt der Regel. Sie können den ersten Satz im Methodencode hinzufügen:

konsole.log(Regel);

Sie können die Regelparameter ausdrucken, um die Objektdaten dieser Regel anzuzeigen.

Wert: Der Wert des Attributs, der überprüft werden muss.

callback: zeigt auf die Callback-Funktion am Ende der Überprüfung. Wenn die Überprüfung erfolgreich ist, wird callback() aufgerufen. Wenn dies fehlschlägt, wird im Allgemeinen das folgende Format verwendet:

Rückruf (neuer Fehler (,spezifische Eingabeaufforderungsinformationen‘));
Oder eine Eingabeaufforderung mit Parametern:

return callback(neuer Fehler(`${rule.field} muss aus alphanumerischen Zeichen in Kleinbuchstaben bestehen`));

Beachten Sie, dass die Zeichenfolgenformatierung nicht in einfache Anführungszeichen, sondern in die Symbole „~“ eingeschlossen wird.

Sie können auch die Methode der offiziellen Website von async-validator verwenden (https://github.com/yiminghe/async-validator):

util.format('%s müssen alphanumerische Zeichen in Kleinbuchstaben sein', rule.field),

Die Util-Datei enthält die Formatmethode. Diese util.ts-Datei befindet sich im src/-Verzeichnis der offiziellen Website. Dies ist eine ts-Datei, die einer öffentlichen Methode ähneln kann.

Tatsächlich können Sie ein Array von Fehlern zurückgeben, also Fehlermeldungen wie die folgenden:

      const Fehler = [];
      errors.push(new Error('Anforderung: Beginnen Sie mit einem englischen Buchstaben, gefolgt von Buchstaben, Zahlen und _-. @-Symbolen'));
      errors.push(neuer Fehler('3444Erforderlich: Englisch'));
      Rückruf (Fehler) zurückgeben;

Aber was die tatsächliche Wirkung betrifft, zeigt das Formular nur die Eingabeaufforderung für die erste Zeile an. Es wird geschätzt, dass das Formular von Element die Anzeige mehrerer Zeilen mit Fehlerinformationen nicht unterstützt.

• Quelle: ist das Attributobjekt zur Aufrufüberprüfung, das zum Anzeigen ausgedruckt werden kann.
• Neben den oben genannten Optionen können auch Zusatzparameter, vor allem vordefinierte Nachrichtenformate, zur Ansicht ausgedruckt werden.

Komplexere Validierer können Parameter annehmen, wie beispielsweise:

// Validierung des Integer-Bereichs export const intRangeValidator = (min, max) => (Regel, Wert, Rückruf) => {
  var isInRange = (Wert >= min) und (Wert <= max);
  const reg = /^-?\d+$/;
  var isInt = reg.test(Wert);
  wenn (isInRange && isInt){
    Rückruf zurückgeben();
  }anders{
    return callback(new Error(`Erfordert eine Ganzzahl zwischen ${min} und ${max} [${min}, ${max}]`));
  }
}

Anwendung:

      'formData.age': [
        {Validator: intRangeValidator(1,100), Auslöser: 'Unschärfe'}
      ],  

Gibt an, dass der Wertebereich des Attributs formData.age eine Ganzzahl von 1 bis 100 ist.

Benutzerdefinierte Validierer bieten Spielraum. Sie können reguläre Übereinstimmungen, numerische Berechnungen, Vergleiche und andere Vorgänge verwenden, um komplexe Überprüfungen durchzuführen, weshalb sie häufiger verwendet werden. Die Verwendung eines benutzerdefinierten Validators kann jedoch manchmal zu umständlich sein.

Benutzerdefinierte Validatoren müssen nicht in externen Dateien platziert werden, sie können auch in Vue-Dateien platziert werden.

In den Daten platziert, aber nicht in der Rückgabe enthalten, ohne abschließendes Komma.

const loginNameValidator = (Regel, Wert, Rückruf) => {
  const reg= /^[a-zA-Z][\w-.@]*$/;
  wenn(Wert == '' || Wert == undefiniert || Wert == null){
    Rückruf();
  }anders {  
    wenn (!reg.test(Wert)){
      callback(new Error('Anforderung: Beginnen Sie mit einem englischen Buchstaben, gefolgt von Buchstaben, Zahlen und _-. @-Symbolen'));
    }anders {
      Rückruf();
    }
  }
}

Oder definieren Sie es direkt in der Regel:

          'formData.loginName': [
            {erforderlich: true, Meldung: „Anmeldename darf nicht leer sein“, Auslöser: ‚blur‘},
            {Validator(Regel, Wert, Rückruf){
              const reg= /^[a-zA-Z][\w-.@]*$/;
              wenn(Wert == '' || Wert == undefiniert || Wert == null){
                Rückruf();
              }anders {  
                wenn (!reg.test(Wert)){
                  callback(new Error('Anforderung: Beginnen Sie mit einem englischen Buchstaben, gefolgt von Buchstaben, Zahlen und _-. @-Symbolen'));
                }anders {
                  Rückruf();
                }
              }                
            }, 
             Auslöser: 'Unschärfe'}
          ],

3.3 Typ

Die grundlegende Verwendung des Typs Typ ist wie folgt:

      'formData.age': [
        {Typ: 'Integer',Nachricht: "Wert muss eine Ganzzahl sein",Trigger: 'Blur'},
      ],

Der Typ ist auch ein Regelelement. Wenn die Typanforderungen nicht erfüllt sind, wird eine Fehlermeldung angezeigt.

Die unterstützten Regeltypen sind wie folgt:

• Zeichenfolge, Zeichenfolgentyp, dies ist der Standardtyp. Wenn der Typ nicht angegeben ist, ist die Standardeinstellung „String“.
• Zahl, numerischer Typ. Umfasst ganze Zahlen und Dezimalzahlen.
• Ganzzahl, Ganzzahltyp.
• float, Gleitkommatyp, kann derzeit keine Ganzzahl sein und muss einen Dezimalpunkt haben.
• Boolesch, Boolescher Typ, Wahr/Falsch-Wert.
• Array, Array-Typ.
• Objekt, Objekttyp, darf kein Array sein.
• Enumeration, Aufzählungstyp, und dann müssen Sie den Aufzählungstyp deklarieren.
• Methode, Funktions- (oder Methoden-)Typ.
• regexp, regulärer Typ, muss ein gültiger regulärer Ausdruck sein und kann mit new RegExp erstellt werden.
• Datum, Datumstyp, der Wert muss in einen gültigen Datumswert konvertierbar sein.
• URL, URL-Typ, der Wert muss dem URL-Format entsprechen.
• E-Mail, E-Mail-Typ, entspricht dem Postfachformat.
• Hex, Hexadezimalformat. Wie beispielsweise 0xFF12.
• beliebig, jeder Typ, keine Einschränkungen.

Die hier aufgeführten URL- und E-Mail-Typen können direkt zur Attributüberprüfung mit zugehörigen Bedeutungen verwendet werden, beispielsweise:

          'formData.email': [
            {Typ: 'E-Mail', Nachricht: "Muss dem E-Mail-Adressformat entsprechen", Auslöser: 'Blur'}
          ],

Datumstypen sind ebenfalls nützlich. Diese integrierten Typen ermöglichen uns die Handhabung, ohne dass wir benutzerdefinierte Validierer verwenden müssen.

Bei numerischen Typen (Zahl, Ganzzahl, Gleitkommazahl) und Booleschen Typen muss eine Typkonvertierung durchgeführt werden, da die Eingabe eine Zeichenfolge ist. Andernfalls schlägt die Überprüfung fehl. Dies beinhaltet die Verwendung von Transform.

3.3 Datentransformation

Transform ist eine Hook-Funktion, die Daten verarbeiten und überprüfen kann, bevor mit der Überprüfung begonnen wird. Wie im folgenden Beispiel gezeigt:

      'formData.age': [
        {
            Typ: "Ganzzahl",
            Meldung: "Wert muss eine Ganzzahl sein",
            Auslöser: 'Unschärfe',
            transform(Wert){return parseInt(Wert);},
        },
      ],

Nach der Konvertierung des Transformtyps können die Validierungsregeln des Attributs formData.age normal verwendet werden, andernfalls schlägt die Typvalidierung immer fehl. (Hier liegt tatsächlich ein Problem vor, z. B. wenn die Ausgabe von Werten in der Form 12ab zulässig ist und parseInt den Wert 12 erhält.)

Für die Typkonvertierung hat transform einen prägnanteren und strengeren Ausdruck:

  'formData.age': [
    {
        Typ: „Ganzzahl“,
        Meldung: "Wert muss eine Ganzzahl sein",
        Auslöser: 'Unschärfe',
        transform: Zahl},
    },
  ],

Zeigt die Konvertierung in einen numerischen Typ an, und das war's. Werte von 1,2 oder 12ab bestehen die Überprüfung nicht.

Neben der Typkonvertierung kann transform auch andere Verarbeitungsvorgänge ausführen, beispielsweise:

          'formData.age': [
            {Typ: 'Zeichenfolge', Muster:/1/, Nachricht: "Der Wert muss eine Zahl zwischen 1 und 100 sein", Transform (Wert) {Return parseInt (Wert)>=1 && parseInt (Wert)<=100 ? "1" : "0";},}
          ],  

Ist gleich einem Wert:

          'formData.age': [
            {Typ: 'Zeichenfolge', Muster:/1/, Nachricht: "Der Wert muss 50 sein", Transform(Wert) {Rückgabewert == "50" ? "1" : "0";},}
          ],  

Ungleich einem Wert:

      'formData.age': [
        {Typ: 'Zeichenfolge', Muster: /0/, Nachricht: "Der Wert kann nicht 50 sein", Transform (Wert) {Rückgabewert == "50"? "1": "0";},}
      ],  

3.4. Reichweite

Der Bereich ist kein Attributfeld der Regel, er wird durch die Min- und Max-Attribute wiedergegeben.

Wenn der Typ eine Zeichenfolge oder ein Array ist, geben Min. und Max. die Länge an.

Wenn der Typ ein numerischer Typ (Zahl, Ganzzahl, Gleitkommazahl) ist, geben Min. und Max. den Wertebereich an. wie:

  'formData.age': [
    {
        Typ: „Ganzzahl“,
        Meldung: "Der Wert muss eine Ganzzahl zwischen 1 und 100 sein",
        Mindestens: 1,
        max:100,
        Auslöser: „Unschärfe“,
        transform:Zahl,
    },
  ],

Auf diese Weise kann die Bereichsprüfung die integrierten Eigenschaften der Regel direkt verwenden und in der Regel beschrieben werden, ohne dass der Validator intRangeValidator und die reguläre Übereinstimmungsmethode verwendet werden müssen.

3.5 Aufzählungswerte

Beispielverwendung von Enumerationswerttypen:

          'formData.idType': [
            {
                Typ: 'enum', enum: [2,4,6], Nachricht: `Ergebnis existiert nicht`, Auslöser: ['ändern', 'unscharf machen'], transform(Wert) {return Number(Wert) * 2},
            },
          ],  
  oder:

      'formData.geschlecht': [
        {
            Typ: 'enum', enum: ['männlich', 'weiblich'], Nachricht: `Ergebnis existiert nicht', Auslöser: ['ändern', 'verwischen'],
        },
      ],  

Bei der Nutzung treten folgende Probleme auf:

• Die Reaktion ist ziemlich langsam, d. h. bei den ersten Eingaben erfolgt keine Überprüfung. Sobald die Überprüfung erfolgt ist, funktioniert alles andere einwandfrei.
• Im letzteren Fall, wo der Bereich eine Sammlung von Zeichenfolgen ist, funktioniert die Validierung einwandfrei. Im ersten Fall, das heißt, der Bereich ist eine Ganzzahl, besteht auch 0 die Prüfung, was dazu führt, dass auch jede andere Zeichenfolge die Prüfung besteht, was ein Fehler ist.

Daher können Sie den Bereich auch mithilfe von Zeichenfolgenaufzählungswerten überprüfen:

          'formData.age': [
            {
                Typ: "Aufzählung",
                Aufzählung:["1"],
                Meldung: "Der Wert muss eine Zahl zwischen 1 und 100 sein",
                transform(Wert){
                    wenn (!isNaN(Wert)){
                      returniere parseInt(Wert)>=1 und parseInt(Wert)<=100 ? "1" : "0";
                    }anders{
                      gibt "0" zurück;
                    }
               }
            },
          ],  

Hinweis: Zu diesem Zeitpunkt wird davon ausgegangen, dass 1e3 und 9e811 die Überprüfung bestanden haben, da die Funktion parseInt nur die Ziffern vor e akzeptiert und isNaN sie als Zahlen betrachtet. Es scheint, dass es noch mit den regulären Regeln koordiniert werden muss.

3.6 Regelmäßiges Muster

Das Musterattribut ist die Prüfregel für die Übereinstimmung mit regulären Ausdrücken, beispielsweise:

          'formData.loginName': [
            {erforderlich: true, Meldung: „Anmeldename darf nicht leer sein“, Auslöser: ‚blur‘},
            {Muster:/^[a-zA-Z][\w-.@]*$/,
             Nachricht: 'Anforderungen: Beginnen Sie mit einem englischen Buchstaben, gefolgt von Buchstaben, Zahlen und _-.@-Symbolen',
             Auslöser: 'Unschärfe'}
          ],

Die Wirkung ist die gleiche wie beim vorherigen Validator loginNameValidator. Der Unterschied besteht darin, dass loginNameValidator wiederverwendet werden kann, eine regelmäßige Validierung aufrechterhält und Sie bei Bedarf nur eine Stelle ändern müssen. Dies ist bei Mustern nicht der Fall. Durch die Verwendung von Mustern kann jedoch die Notwendigkeit verringert werden, benutzerdefinierte Validierer zu schreiben, und den Benutzern eine Auswahlmöglichkeit gegeben werden.

Mithilfe des Musterattributs können Sie überprüfen, ob ein Wert einem bestimmten Wert entspricht.

Ist gleich einem Wert:

{Muster:/120/,Nachricht:'Muss 120 sein',Auslöser: 'Unschärfe'}

Bei JS-regulären Ausdrücken können Sie diese zunächst mit dem Online-Testtool für JS-reguläre Ausdrücke testen, um zu prüfen, ob sie den erwarteten Effekt erzielen. js-regulärer Ausdruck Online-Testadresse: https://c.runoob.com/front-end/854.

3.7. Länge len

Das Attribut „len“ gibt die Länge an, wenn der Typ „String“ oder „Array“ ist. Wenn es sich um einen numerischen Typ handelt, bedeutet dies, dass der numerische Wert der Wert des Längenattributs ist.

Wenn das Längenattribut zusammen mit den Min- und Max-Attributen auftritt, hat das Längenattribut eine höhere Priorität.

Mit dem len-Attribut lässt sich die formatierte Zeichenfolge überprüfen, beispielsweise die Länge einer Ausweisnummer.

Mit len ​​kann auch geprüft werden, ob es einem bestimmten Wert entspricht, beispielsweise:

  'formData.age': [
    {
        Typ: „Ganzzahl“,
        Meldung: "Der Wert muss 6 Jahre alt sein",
        Länge: 6,
        Auslöser: „Unschärfe“,
        transform:Zahl,
    },
  ],

3.8 Leerzeichen

Leer bedeutet, dass die Zeichenfolge ausschließlich aus Leerzeichen besteht. Der Regeltyp muss Zeichenfolge sein. Wenn die Regel zutrifft, wird ein Alarm angezeigt. wie:

          'formData.email': [
             {whitespace: true, message: ‚Nur Leerzeichen‘, trigger: ‚blur‘}
          ],

Wenn der Wert ein Leerzeichen ist, wird eine Warnung angezeigt.

Wenn Sie nicht möchten, dass Leerzeichen die Validierung beeinträchtigen, können Sie dies mit „transform“ handhaben:

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

3.9, i18n

Message unterstützt i18n, also Internationalisierung. Wenn Sie vue-i18n integrieren, ist die Verwendung des Nachrichtenattributs wie folgt:

Nachricht: () => diese.$t('über') 

In der chinesischen Sprache wird „About“ angezeigt, und in der englischen Sprache wird „about“ angezeigt.

Natürlich können Sie es auch durch jede andere Funktion ersetzen, wie zum Beispiel:

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

4. Erweiterter Modus der Regelüberprüfung

4.1. Asynchroner Validator

Der asynchrone Validator wird für den Remotezugriff verwendet und nutzt Ajax oder Axios, um Daten anzufordern, die Antwortdaten zu überprüfen oder Ausnahmen abzufragen.

Die lokale Seitenüberprüfung ist eine serielle Überprüfung. Dabei werden die Überprüfungsregeln jedes Felds einzeln überprüft. Wenn dies fehlschlägt, wird „Überprüfungsfehler“ zurückgegeben.

Bei der Remote-Verifizierung handelt es sich um eine asynchrone Verifizierung. Mehrere Anfragen haben unterschiedliche Antwortzeiten und die Reihenfolge der Antworten kann nicht vorhergesagt werden.

Die Rolle der asynchronen Validierung: Das Front-End und das Back-End können für dieselben Attributfelder dieselben Validierungsregeln verwenden, und die Validierung wird einheitlich vom Back-End bereitgestellt. Dadurch erhöhen sich jedoch auch die Kosten für die Front-End- und Back-End-Kommunikation sowie die Konsistenzpflege.

Der asynchrone Validator wird noch nicht verwendet, hier ist das Beispiel von der offiziellen Website:

asyncField1:{asyncValidator: myAsyncValidator}
  myAsyncValidator kann an einer ähnlichen Position wie validator platziert werden. Nehmen Sie an, dass es in den Daten platziert ist.

const myAsyncValidator = (Regel, Wert, Rückruf) => {
      ajax({
        URL: „xx“,
        Wert: Wert,
      }).dann(Funktion(Daten) {
        Rückruf();
      }, Funktion(Fehler) {
        Rückruf (neuer Fehler (Fehler));
      });
    }

Promise asynchrone Feldüberprüfung:

 const myAsyncValidator = (Regel, Wert) => {
      Rückkehr ajax({
        URL: „xx“,
        Wert: Wert,
      });
    }

Der Unterschied besteht darin, dass die asynchrone Feldüberprüfung von Promise erfordert, dass Benutzer ihre eigene .then/.catch-Verarbeitungslogik schreiben, und dass keine Rückrufe unterstützt werden.

Bei der asynchronen Überprüfung ist auch die Optionseigenschaft beteiligt.

Optionen: { zuerst: true },

first ist wahr und gibt an, dass, wenn mehrere asynchrone Prüfungen nach der ersten Prüfung fehlschlagen, andere asynchrone Prüfungen nicht verarbeitet werden.

4.2 Tiefe Regeln

Zur Verifizierung eines Objekts oder Arrays muss jedes einzelne Element (Mitglied) verifiziert werden, hierzu kommen Deep Rules zum Einsatz.

Detaillierte Regeln umfassen zwei Attribute: Felder und Standardfeld.

Wie im Beispiel der offiziellen Website zu sehen (leicht abgewandelt entsprechend der üblichen Form):

Detaillierte Untersuchung des Objekts:

Regeln:
  Adresse: [{
    Typ: "Objekt",
    erforderlich: wahr,
    Optionen: { zuerst: true },
    Felder: {
      Straße: [{ Typ: 'Zeichenfolge', erforderlich: true }],
      Stadt: [{ Typ: 'Zeichenfolge', erforderlich: true }],
      zip: [{ Typ: 'Zeichenfolge', erforderlich: true, Länge: 8, Nachricht: 'ungültige Zip-Datei' }],
    },
  }],
  Name: [{ Typ: 'Zeichenfolge', erforderlich: true }],
};

Tiefgehende Validierung von Arrays:

Regeln:
  Rollen: [{
    Typ: "Array",
    erforderlich: wahr,
    Länge: 3,
    Felder: {
      0: [{ Typ: 'Zeichenfolge', erforderlich: true }],
      1: [{ Typ: 'Zeichenfolge', erforderlich: true }],
      2: [{ Typ: 'Zeichenfolge', erforderlich: true }],
    },
  }],
};

Die gründliche Validierung von Arrays scheint albern. Jedes Mitglied muss Validierungsregeln festlegen. Bei dynamischen Arrays weiß ich anscheinend nicht, wie ich sie festlegen soll.

Das Attribut defaultField ermöglicht uns, einheitliche Regeln für die Feldvalidierung festzulegen. Diese Eigenschaft kann auf Validierungsattributfelder oder auf Felder angewendet werden.

Zum Beispiel:

Regeln:
  URLs: [{
    Typ: "Array",
    erforderlich: wahr,
    Standardfeld: { Typ: 'URL' },
  }],
};

Wenn es sich um ein Array von Objekten handelt, wie wird es festgelegt? Folgende Methoden stehen zur Verfügung:

Regeln:
  Personen: [{
    Typ: "Array",
    erforderlich: wahr,
    Standardfeld: {
        Typ: "Objekt",
        erforderlich: wahr,
        Felder: {
            Adresse: [{
                Typ: "Objekt",
                erforderlich: wahr,
                Felder: {
                    Straße: [{ Typ: 'Zeichenfolge', erforderlich: true }],
                    Stadt: [{ Typ: 'Zeichenfolge', erforderlich: true }],
                    zip: [{ Typ: 'Zeichenfolge', erforderlich: true, Länge: 8, 
                           Nachricht: 'ungültige Postleitzahl' }],
                },
            }],
            Name: [{ Typ: 'Zeichenfolge', erforderlich: true }],                  
        }
    }
  }],
};

Arrays innerhalb von Objekten, Objekte innerhalb von Unterobjekten, es scheint ein bisschen kompliziert.

4.3 Dynamischer Regelsatz

Manchmal kommen unterschiedliche Modi in das Formular ein und es müssen unterschiedliche Regeln angewendet werden. Für Hinzufügungs- und Bearbeitungsvorgänge wird dieselbe Seitenkomponente angezeigt. Allerdings sind die Attributfelder, die auf der Seite überprüft werden müssen, derzeit unterschiedlich. Wie werden sie festgelegt?

Es gibt zwei Lösungen. Lösung 1 besteht darin, zwei Regelsätze zu konfigurieren und sie entsprechend den unterschiedlichen Modi umzuschalten; Lösung 2 besteht darin, den gesamten Regelsatz zu konfigurieren, entsprechende Attributfelder und Regeln entsprechend den unterschiedlichen Modi zu extrahieren und den Regelsatz dynamisch zu erstellen.

4.3.1. Wechsel des Verifizierungsregelsatzes

Wechseln Sie den Validierungsregelsatz. Der Beispielcode lautet wie folgt:

      // Datenteil // aktueller Regelsatz rules:{},
      // Modus 1 Regelsatz rules1:{
         ...
      },
      // Modus 2 Regelsatz rules2:{
          ...
      },

      // Methodenteil // dynamisches Umschalten // Seiteninitialisierung init(obj,data){
        diese.vorherigeForm = obj;

        //Seite so einstellen, dass sie sichtbar ist. this.visible = true;

        //Führen Sie dies aus.$nextTick(()=>{
          // Alle Feldwerte der aktuellen Seite zurücksetzen this.$refs['form'].resetFields();

          wenn (Daten){
            // Modus 1
            dieser.Formular.Mustertyp = 1;        
          }anders{
            // Modus 2
            dieser.Formular.Mustertyp = 2;
          }        
          // Validierungsregeln festlegen this.setValidRules(this.form.patternType);
        }
    },
      setValidRules(Mustertyp){
        wenn(Mustertyp == 1){
            diese.Regeln = diese.Regeln1;
        }sonst wenn(Mustertyp == 2){
            diese.Regeln = diese.Regeln2;
        }
      },

Auf diese Weise wird der Regelsatz für die Überprüfung entsprechend den unterschiedlichen Modi umgeschaltet. Um beim Wechseln der Regeln sofort eine Regelvalidierung durchzuführen, müssen Sie die Funktion „validate-on-rule-change“ von el-form auf „false“ setzen, d. h.:

<el-form ref="Formular" :model="Formular" :rules="Regeln" 
         :Validierung bei Regeländerung=false 
         Klasse = "Benutzerbearbeitung" Beschriftungsbreite = "100px" Stil = "Zeilenhöhe: 30px;">

4.3.2 Dynamisches Erstellen von Validierungsregelsätzen

Erstellen Sie dynamisch einen Validierungsregelsatz. Der Beispielcode lautet wie folgt:

      // Datenteil // aktueller Regelsatz rules:{},
      // Alle Regeln allRules:{
          'formData.loginName': [
            {erforderlich: true, Meldung: „Anmeldename darf nicht leer sein“, Auslöser: ‚blur‘},
            {validator:loginNameValidator, Auslöser: "unscharf"}
          ],
          'formData.passwd': [
            {erforderlich: true, Meldung: „Das Passwort darf nicht leer sein“, Auslöser: ‚blur‘},
            {min: 6, max: 18, Nachricht: „Passwort 6-18 Ziffern“, Auslöser: ‚blur‘}
          ],
          'formData.email': [
             {Typ: 'E-Mail', Nachricht: 'Muss dem E-Mail-Format entsprechen', Auslöser: 'Unschärfe'}
          ],          
          Geschlechtsbezeichnung:
            {erforderlich: true, Nachricht: „Geschlecht darf nicht leer sein“, Auslöser: ‚ändern‘},
          ],
          BenutzerTypbezeichnung: [
            {erforderlich: true, Meldung: „Benutzertyp darf nicht leer sein“, Auslöser: ‚ändern‘},
          ],
          Abteilungsbezeichnung: [
            {erforderlich: true, Meldung: "Abteilung darf nicht leer sein", Auslöser: 'ändern'},
          ]
      },
          
      // Methodenteil // dynamisches Umschalten // Seiteninitialisierung init(obj,data){
        diese.vorherigeForm = obj;

        //Seite so einstellen, dass sie sichtbar ist. this.visible = true;

        //Führen Sie dies aus.$nextTick(()=>{
          // Alle Feldwerte der aktuellen Seite zurücksetzen this.$refs['form'].resetFields();

          wenn (Daten){
            // Modus 1
            dieser.Formular.Mustertyp = 1;        
          }anders{
            // Modus 2
            dieser.Formular.Mustertyp = 2;
          }        
          // Validierungsregeln festlegen this.setValidRules(this.form.patternType);
        }
    },
      setValidRules(Mustertyp){
        wenn (Mustertyp == 1){
          // Modus 1
          //Erst löschen, dann this.rules = {} festlegen;
          diese.Regeln['genderLabel'] = diese.alleRegeln['genderLabel'];
          this.rules['Benutzertypbezeichnung'] = this.alleRules['Benutzertypbezeichnung'];
          this.rules['deptLabel'] = this.alleRules['deptLabel'];
          diese.Regeln['formData.email'] = diese.alleRegeln['formData.email'];
        } anders{
          // Modus 2, Überprüfung von Anmeldename und Passwort erforderlich this.rules = {};
          this.rules['formData.loginName'] = this.allRules['formData.loginName'];
          diese.Regeln['formData.passwd'] = diese.alleRules['formData.passwd'];
          diese.Regeln['genderLabel'] = diese.alleRegeln['genderLabel'];
          this.rules['Benutzertypbezeichnung'] = this.alleRules['Benutzertypbezeichnung'];
          this.rules['deptLabel'] = this.alleRules['deptLabel'];
          diese.Regeln['formData.email'] = diese.alleRegeln['formData.email'];
        }
      },

Sie müssen außerdem „validate-on-rule-change“ von „el-form“ auf „false“ setzen.

4.4. Dynamische Tabellenfeldüberprüfung

Einige Formulare verwenden bearbeitbare dynamische Tabellen, z. B. das Hinzufügen einer Datenzeile, das direkte Eingeben von Daten in die Datenzeile und das anschließende Senden. Jetzt müssen Sie die Eingabe in jedem Feld in der Datenzeile überprüfen.

Es gibt 2 Möglichkeiten.

Lösung 1 verwendet das Standardfeld der Deep-Regeln, um eine Feldvalidierung am Objekt-Array durchzuführen, wie im obigen Beispielcode gezeigt.

Lösung 2: Verwenden Sie das Regelattribut auf der Ebene des El-Form-Elements, um die Feldregeln zu binden.

4.5. Überprüfung von Verbindungen in mehreren Feldern

Die Anwendungsszenarien der gemeinsamen Überprüfung mehrerer Felder sind relativ häufig, beispielsweise das Problem des Textanfangs. Unterschiedliche ID-Typen haben unterschiedliche Überprüfungsregeln. Bei der Kennwortüberprüfung müssen beispielsweise die beiden Kennwörter identisch sein. Beispielsweise darf die Einkaufsmenge die Lagermenge nicht überschreiten, die Startzeit des Zeitraums darf nicht größer als die Endzeit sein usw.

Die wichtigste Fähigkeit besteht darin, die erste Parameterregel des Validators zu verwenden, um ein oder mehrere benutzerdefinierte Attribute hinzuzufügen und die Informationen zur Verarbeitung an den Validator zu übergeben. So verwenden Sie es:

Nehmen wir beispielsweise an, dass die Validierung des Felds „formData.email“ vom Wert des Benutzertyps abhängt.

          'formData.email': [            
             {Validator: idFieldWithTypeValidator, Auslöser: "Unschärfe",}
          ],

Es gibt keine Möglichkeit zum anfänglichen Binden:

          'formData.email': [            
             {Validator: idFieldWithTypeValidator, Auslöser: „Unschärfe“, „Benutzertyp“: this.form.formData.usertype}
          ],

Wenn es so geschrieben ist, zeigt der Browser-Debugger einen Fehler an, der darauf hinweist, dass beim Aufruf von resetFields ein Fehler aufgetreten ist.

Daher lautet die korrekte Form:

      'formData.email': [            
         {Validator: idFieldWithTypeValidator, Auslöser: "Unschärfe",}
      ],

oder:

      'formData.email': [            
         {Validator: idFieldWithTypeValidator, Auslöser: „Unschärfe“, „Benutzertyp“: 0}
      ],

Legen Sie dann beim Initialisieren der Seite oder in der Ereignismethode „chage“ beim Ändern des Auswahlfelds den Wert des Attributs „userType“ in der Regel dynamisch fest:

diese.Regeln['formData.email'][0]['Benutzertyp'] = diese.form.formData.Benutzertyp;

Die Testergebnisse zeigen, dass $set nicht für dynamische Bindungen verwendet werden kann, d. h. die folgenden Anweisungen haben keine Wirkung:

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

OK, jetzt können wir einen gemeinsamen Validator idFieldWithTypeValidator schreiben. Der Einfachheit halber schreiben Sie in den Datenabschnitt:

      const idFieldWithTypeValidator = (Regel, Wert, Rückruf) => {
        // Benutzertyp abrufen console.log(rule);
        Rückruf zurückgeben();
      }

Testen Sie es und geben Sie die Druckinformationen der Regel wie folgt in der Browserkonsole aus:

{
    "Benutzertyp": 2,
    "Feld": "formData.email",
    "fullField": "formData.email",
    "Typ": "Zeichenfolge"
}

An diesem Punkt wurde der Benutzertyp über den Regelparameter übergeben und jetzt kann eine gemeinsame Überprüfung durchgeführt werden.

  importiere {loginNameValidator,phoneNoValidator,idNoValidator,eMailValidator} aus '@/common/validator.js'
  Standard exportieren {
    Daten() {
      // ID-Feldvalidator für verschiedene Typen const idFieldWithTypeValidator = (Regel, Wert, Rückruf) =>{
        // Benutzertyp abrufen console.log(rule);
        wenn (Regel.Benutzertyp == 1){
          // Mobiltelefonnummer phoneNoValidator(rule, value, callback);
        }sonst wenn(Regel.Benutzertyp == 2){
          // ID-Nummer idNoValidator(Regel, Wert, Rückruf);
        }sonst wenn(Regel.Benutzertyp == 3){
          // E-Mail
          eMailValidator (Regel, Wert, Rückruf);
        }
      }

      zurückkehren {
          ....
      }            
    },
    ...
  }

Unter ihnen sind phoneNoValidator, idNoValidator und eMailValidator jeweils Handynummern-, ID-Kartennummern- und E-Mail-Format-Validatoren, die von validator.js ausgegeben werden. Der Validator idFieldWithTypeValidator ruft die entsprechenden Validatortyp-Validatoren entsprechend dem Wert des Parameters userType auf. Natürlich können Sie im Methodencode von idFieldWithTypeValidator auch den Code jedes einzelnen Validators verschieben, ohne den externen Validator aufzurufen.

5. Referenzen

Neben den Informationen auf der offiziellen Website verweist dieser Artikel auch auf die folgenden Artikel:

[1] Eine kurze Analyse des Quellcodes des Async-Validators, https://zhuanlan.zhihu.com/p/32306570?edition=yidianzixun&utm_source=yidianzixun&yidian_docid=0I5IikUl.

[2] Grundlegende Elemente der Elementformularvalidierung in Vue, https://www.php.cn/js-tutorial-406545.html.

[3] Konfiguration der Validierungsregeln für Element-UI-Formulare, https://www.cnblogs.com/loveyt/archive/2020/07/11/13282518.html.

[4] Element UI -Verwendungstipps - Detaillierte Beschreibung der Formularvalidierungsregeln, https://www.cnblogs.com/xyyt/p/13366812.html

Dies ist das Ende dieses Artikels über die Implementierung von Vue Element-UI-Formularvalidierungsregeln.