What would you change in Vuelidate?

As the saying goes, “After the bitter comes the sweet”, and after a while of silence, we have some good news.

Our project lead Damian has made some very good progress on rewriting the library from scratch using the new Vue Composition API, while still keeping the API relatively close to the current version of Vuelidate. This means the current, model oriented, options-based approach to declaring validations will stay as it is.

The time has come to ask you, the users, what do you find annoying, hard, or just missing from Vuelidate? What would you like us to change or implement?

The project has reached a prototyping phase, where we are open for suggestions, changing the API, to improve the experience for you, the users.

Please leave a ticket, explaining what your idea is and your proposed change, using the RFC template in the Vuelidate Issues. The process will go for a week or two, after which we will close further submissions, go through and filter the feasible ideas.

We are very excited about the future of Vuelidate, and hope so are you!

Link to Issues
Post your Idea

Comments

[desislavsd]

What do you think of registering the validators via chaining:

import { validator } from 'vuelidate'

let validations = {
    name: validator().required.minLen(3).maxLen(10).alpha,
    email: validator().email.required,
    age: validator().numeric.required
}

Though, tree shaking might suffer :(

[desislavsd]

I would like to have some mechanism to generate error messages for each value that is being validated. Here is possible solution:

Option during setup to provide function for generating validation messages. The function should receive the property that is being validated, its value and the validator that is failing. Something like:

Vue.use(Vuelidate, {
    messageGenerator({prop, validator, value}){

        if(validator == 'required')
            return `${prop} is required`

        return `Please enter valid ${prop}`
    }  
})

Then this message should be accessible as $v[prop].$message or $v[prop].$error.

Think this messaging system might be sufficient in most cases.

Also each validator might receive second argument that would be the error message in case it fails or there should be special errorMessage() validator that does the same as the function above:

   let validations = { 
           name: {
               required,
               messageValidator: messageValidator({value, prop, validator}){
                   return `invalid name`
               } 
           } 
       }

[Dobromir Hristov]

Hey!
Yes this is planned and we are adding it as we speak :)

[JeDTr]

what do you think about yup style: github.com/jquense/yup
we can pass message into the schema

const validation = {
    email: required('email is a required field').email('invalid email'),
    password: required('name is a required field'),
}

[Metch P]

Debounced async validations are pain

[Dobromir Hristov]

True. Post a ticket in the RFC proposing your idea, so we don't loose it :)

[Paolo]

server side response validation to update state of $v