#vuecember2020 #vuejs

Vuelidate

Der Kunde ist König

und das gilt auch in der Welt der Software. Aber auch für Kund:innen gibt es Regeln. Zum Beispiel muss man im Laden oder in der Bahn sicherstellen, dass die Mund-Nasen-Bedeckung auch – wer hätte es gedacht – die Nase bedeckt.
Von den Besucher:innen unserer Website bzw. den Nutzer:innen unserer Applikation erwarten wir ebenfalls, dass sie sich an bestimmte Regeln halten. Wenn wir für unsere Versicherungs- oder Lotterieunternehmen beispielsweise persönliche Informationen erfassen müssen, dann freuen wir uns, wenn Erika Mustermann als Wohnort kein Mosaik aus Sonderzeichen angibt und ihr Geburtsdatum mindestens ein paar Jährchen vor dem Tag der Eingabe liegt, zumindest solange Zeitreisen noch Fiktion sind.
Wenn Erika sich nicht an die Regeln hält und ihre Angaben von dem abweichen, was wir erwarten und verarbeiten können, können wir Erika Hinweise geben, die ihr erklären, was sie falsch gemacht hat. Dieser Mechanismus der Formular-Validierung ist nicht nur für uns wichtig, sondern für alle Websites und Apps, die Informationen und/oder Bestätigungen durch User:innen erfordern. Damit wir als Entwickler:innen nicht jedes Mal das Rad neu erfinden müssen, gibt es dafür Libraries. Hinter dem dritten VueCember-Türchen versteckte sich bereits ein Artikel zu VeeValidate, heute schauen wir uns Vuelidate an.

Auch Vuelidate bietet built-in Validierungsregeln, kann unkompliziert um Regeln anderer Libraries (wie z. B. Moment.js oder date-fns für Datumsvalidierungen) erweitert werden und erlaubt das Hinzufügen eigener Regeln. Anders als VeeValidate setzt Vuelidate nicht voraus, dass die zu validierenden Daten Form-Input-Binding mit v-model verwenden. Dadurch ist es besser dazu geeignet, auch andere reaktive Daten wie computed properties zu validieren. Eine weitere Besonderheit von Vuelidate liegt darin, dass es Modell-basiert ist. Das bedeutet, dass es separat von Template und restlichem Code als Validierungsobjekt namens validations auftaucht, welches die Datenstruktur dessen widerspiegelt, was wir validieren wollen. So bleibt das Template, insbesondere bei komplexen Formularen, die viele Felder und vielleicht sogar Abhängigkeiten zwischen den Feldern haben, übersichtlich. Unsere Validierungen finden sich alle gesammelt und gut lesbar an einer Stelle in der entsprechenden Datei.

Das sieht dann zum Beispiel so aus:

validations: %7B
  insuranceStart: %7B
    required,
    isValidDate,
  %7D,
  policyHolder: %7B
    required,
    address: %7B
      zip: %7B
      required,
      %7D,
      city: %7B
        required,
      %7D,
    %7D,
  %7D, 
  insuredPersons: %7B
    required,
    $each: %7B
      dob: %7B
        required,
        isValidDate,
        isInPast,
        isAboveMinAge: isAboveMinAge(18),
      %7D,
    %7D,
  %7D,
%7D

Das Validierungsobjekt bildet die Verschachtelungen der Daten ab. Es lässt uns über inhaltlich zusammengefasste Daten iterieren – genauso können wir darin aber auch Felder nach Validierungen gruppieren, die im Formular nichts miteinander zu tun haben.

In den Vue-Devtools finden wir die computed property $v. Diese liefert uns Informationen über die bisherige Interaktion von Erika sowohl mit dem Formular im Allgemeinen als auch mit allen zu validierenden Feldern. $v-Values wie z. B. $dirty, $error oder $invalid repräsentieren den aktuellen Stand der Validierung. Das kann dann in etwa so aussehen wie hier in diesem Beispiel von CSS-Tricks, in dem wir nur name als Angabe haben und noch nichts ins Inputfeld eingegeben wurde:

Vuelidate Devtools example.png

tl;dr? Zum Setup von Vuelidate in deinem Projekt geht's hier entlang.