Validation

[hfekete]

Description

A bit on what we are doing with validation currently, and what we want to do / miss.

Validation Lib

Currently we picked Zod as a validation library.
Reason for picking Zod after some basic research was:

• It is oriented towards Typescript, while some other libs had issues/more work to make it behave nicely
• It is one of the 4 easy plug&play libs for the NuxtUI (ui framework we use)
• It was on upward trend and more popular then other libs we looked into.

Some other libs we looked into are vuelidate, valibot and yup

Validation TODOs

• User experience guiding principle: Inform the user as soon as possible that a known error has been made.
• If in error state, update the field error message on keystroke, when field becomes valid (unless exception exists to run validation on specific event)

Current approach

Our approach for doing validation is what is both default and widely used approach. We validate fields on Schema level (form level). This is compatible with Zod, and Nuxt UI idea of validation. Schema validation means we define all the fields we will have on a form in an JS object, and provide validation rules required for it.

Zod allows us to select when we do validation, and what rules while NuxtUI provide seamless integration into form and error message display.

Missing

What we are currently missing, and is hard to do without extensive customization on component/error label level is doing different validations on different triggers. E.g. our UX designers would like to have option to have some of validation done on blur, and other validation done on keyup for certain inputs.

With current selection of tools this is not possible out of the box. Zod allows us to select when we want to do the validation, what events, but does not let us select when we do specific validation. For example we can tell Zod that we want to validate on keyup and onSubmit and onblur, and all of this is for each field defined in schema on the form. What we cannot do is validate some inputs with one set of rules on change and with another set of rules on key up.

[thorwolpert]

Can we say that is acceptable for now?

What we cannot do is validate some inputs with one set of rules on change and with another set of rules on key up.

As one of our guides is to see how close we can get without doing a lot of extra things (yet).