Sorry if you deem this as inappropriate use of github issues, feel free to close.
However I was hoping to get your take on using this along side server side errors, as obviously clientside can only get half the job done, for example if we used an Ajax call to submit a form and we had several issues come back, how could you avoid conflicts, e.g. Showing duplicate/conflicting messages? Maybe like an email address is already in use, but the frontend validation says it's okay? Will we need duplicate markup to display each??
Hopefully this makes sense, many thanks for your hard work :)
There are multiple ways to handle this, you can add your own unique role which connects to your backend API that verifies if it is a valid email or whatever, this is however a naive way to do it.
Another way is to verify what you can on the client side, then after submission you can check the backend result and add errors manually, remember that the errors object is just a collection wrapper around a simple array:
this.$validator.validateAll().then(() => {
// send your data to the backend.
this.submit().then(() => {
// all went well.
}).catch(response => {
// some errors were encountered
// analyse the response and populate the errors object with errors.add
// ex: errors.add('field', response.errors.field, 'unique');
})
}).catch(() => {
// client side errors.
});
You can use this way to also display other errors like authentication errors as well.
Ah I think the 'errors.add' method would be the one that's key here!! Thanks :)
Would it be possible to also push a server message to display, as o assume the 3rd param maps the rule to a predefined error?
Errors are stored as objects, there is no limitation to the nature of the data you can put there. Actually you only need to pass the first two parameters, but it is usually a good idea to map errors to rules, even if said rules don't exist within the validator.
Also You can create a transformer or a mapper that takes errors from the backend and formats them to be added by the plugin, should clean up your code even more.
Lovely :) thanks for the info, will definitely give this a whirl on our next project!
Hey, just for what it's worth, I am here looking for the same thing. I am working with Laravel. The idea behind acknowledging server-side validation errors responses is that the server is the main source of truth, a programmer error or something may mean that a validation test is performed server-side but not client-side, or changes over time may cause this, and I want to handle this elegantly. It also allows me to sometimes be lazy about implementing API-based "unique" and "unique-if" validations and stuff like that.
The solution above likely works but seems just a little hack-y, it might be cool to be able to do something like have a method for displaying a custom error message or adding it to the error message stack, and make it disappear on the input DOM 'blur' event, and/or allow programmatic clearing of the message to deal with more complex cases. The validation test methods fail until the message is cleared.
@SirLamer Is reasoning what you are looking for?
https://github.com/logaretm/vee-validate/commit/1a8e33f3b9ca767bbd6e92adfe0c2e4a15d7d385#diff-d86f47aab4bdaf5a5f77c225885671c0R448
It is implemented long time ago, but not documented. Basically it lets you create your custom rules, and define a data object that you need to use to generate the errors, you can use the data object to pass reasons for failing from the backend.
Dear @logaretm , first of all thank you so much for the awesome library, and I really mean it. During the years I worked with many client validators library (included judge), but to be honest vee-validate is just light years ahead of everything else. Really a complete, versatile and flexible package. Thank you again.
Now let's get to business with the annoying questions...
I am catching errors also server side, and I would love to show them with the same mechanism that I use client side (the vee-validate way).
I am using a full serverless architecture, meaning my server side code is really bare minimum.
I tried to put together a bit of code to show same client side error but coming from server side (meaning using same message defined in my dictionary, same location etc). Everything works pretty well, except, for the life of me I am not able to pass the field into the message .
in my dictionary under message I have something like this:
required: (field) =>Ouch! We need your ${field} to rock and roll.``
and in a method in . one of my component (the one with the form) I do have the following when I get a response from server with error:
vm.$validator.errors.add('firstName',vm.$validator.dictionary.getMessage('en', 'required'))
where vm is a variable equal to this.
I see in my page under the field that the message gets showed, but instead of having the field name, it has undefined:
`Ouch! We need your _undefined_ to rock and roll.``
My question is simple, how I can pass the field variable into getMessage used with the dictionary?
I looked everywhere, without luck.
Thanks:)
@logaretm never mind, I was probably very sleepy:) I found the solution and was just there in front of my eyes. Actually getMessage take a data parameter and that is where I pass the field name.
Thanks again...
errors.add('field', response.errors.field, 'unique');
Has this method been changed. I am not being able to dynamically add a error message after I get repsonse from the backend.
I get this error now can't assign to property "scope" on "email": not an object
Seems like this has been moved to an object
errors.add({ field : 'email', msg: 'this is a test', rule: 'unique'});
or simply
errors.add({ field : 'email', msg: 'this is a test'});
this is working as expected.
Most helpful comment
There are multiple ways to handle this, you can add your own
uniquerole which connects to your backend API that verifies if it is a valid email or whatever, this is however a naive way to do it.Another way is to verify what you can on the client side, then after submission you can check the backend result and add errors manually, remember that the errors object is just a collection wrapper around a simple array:
You can use this way to also display other errors like authentication errors as well.