Vee-validate: Latest version does not hold multiple errors per field

Created on 28 Apr 2017  Â·  17Comments  Â·  Source: logaretm/vee-validate

Versions:

  • VueJs: 2.3.0
  • Vee-Validate: 2.0.0-beta.25

Description:

I noticed that the ErrorBag in the latest version does not hold all errors for a field. In otherwords, if I set rules as such: v-validate="'email|min:6'", only 1 error will display at a time.

I browsed around and found another fiddle that displayed multiple errors per field. Saw that it was using an older version. I've provided fiddles for both version below.

I'm assuming this is not expected since http://vee-validate.logaretm.com/examples.html#selectors-example is clearly showing multiples per field? Or maybe I'm not defining something correctly?

Steps To Reproduce:

https://jsfiddle.net/devpake/yrbw8dL5/6/

  • This uses vee-validate 2.0.0-beta.25

https://jsfiddle.net/devpake/dqoL3b5r/4/

  • This uses vee-validate 2.0.0-beta.18
✨ enhancement 📚 docs

Most helpful comment

Understandable. Agreed that having multiple validations available would seem to be a friendly option to have. For example, password validation - it would be annoying for users to be prompted with yet another validation error after correcting one. Probably less aggravating to see all the problems up front than one at a time. But one at a time can work for most. Simplicity usually wins for both use and maintenance.

All 17 comments

An early exit was introduced, so the rules will evaluate the input one at a time, this was done to limit firing async validations will could consume more memory/http calls depending on their implementation.

The example shows the selectors behavior, but I guess that is unclear and I will update the docs section about this. Thanks!

I imagine this would render certain ErrorBag functions useless - like first and firstByRule since we are no longer able to specify a rule.

I left them untouched for compatibility issues, their implementation however doesn't reflect the simpler behavior introduced lately.

In the future we can add an option to choose between behaviors if that is needed, I think the current system is both simple and intuitive, as you would place the heavier/async validations towards the end of the validations.

Understandable. Agreed that having multiple validations available would seem to be a friendly option to have. For example, password validation - it would be annoying for users to be prompted with yet another validation error after correcting one. Probably less aggravating to see all the problems up front than one at a time. But one at a time can work for most. Simplicity usually wins for both use and maintenance.

Agreed I will work on it before the next rc, maybe also add a modifier to allow all validations to run for a specific field.

@logaretm when will the older behavior will be reinstated?

It won't be reinstated by default, you would have to turn it on yourself via config when installing the plugin, but I don't have an exact timeline, but hopefully at the end of the week.

For the record 731fb039eed3b3dcfa81183aad831782fc8cbc0b is the culprit.

@logaretm did you add an option for it? If so could you point me to it.
I have some bugs with the current version I am stuck with and Id like to switch to a more recent one before considering another plugin.

@Mouvedia Are you stuck on this bug, or is there more bugs facing you?

I don't know if this a place but yeah, I have a bug on that version which doesn't trigger vee-validate anymore if you navigate back to a page. As if I had to initialize it myself on the routeupdate event. It might be fixed in a later version though.

Also I find this plugin very unpractical/verbose when used on custom components which embark their own validation.

You can create a new issue for that problem, I will experiment with VueRouter in the meantime.

Regarding components you can skip the verbose data path if your component has a value property that reflects its current value. It is verbose for components because they don't have a standard like the HTML native inputs. I didn't want to force users to follow a specific API for their components because they might not even own the component so they have no control over it, still I'm always looking for ways to improve it, your suggestions will be most welcome.

@logaretm Since I am stuck on beta 22 I can't use injection.
That's one of the reasons of why I am requesting a config option to switch the default behaviour.

@Mouvedia Sorry to keep you hanging for all this time, you can enable the behavior by setting the fastExit option to false when installing the plugin:

Vue.use(VeeValidate, { fastExit: false });

It will be true by default.

@logaretm thanks! Ill try it out right once you release a new version.

Can you add something so that it can be disabled on a per element fashion?
It would locally switch off the currently global behaviour in one way or the other.

I could add a modifier, will have to address other issues first tho.

@logaretm did you add that modifier ?

BTW it seems that errors.has('example') doesn't work correctly when used with fastExit disabled.

Was this page helpful?
0 / 5 - 0 ratings