2.0.0-beta.9

Latest tag broke field dependent rules like confirmed and after and before due to the addition of scopes. should be fixed now.

Scopes

Previously the validator instance had only one scope, the same scope as its owning Vue instance. so duplicate fields would conflict if they had the same name. one way to avoid conflict was to give them different names and give them the same display name. but if you had two forms within the same component and you wanted to display each form errors independently from each other that would be hard to do.

This new release offers scopes to handle this issue, you would give the fields a scope then you can provide a scope to the ErrorBag object methods, so it can locate those errors even if duplicate fields exists across different scopes. this can be done by providing a data-scope attribute on the field or on the form that contains the field.

here is a small example:

HTML:

<div id="app">
    <form data-scope="sign_up">
        <input type="text" name="email" v-validate data-rules="required|email">
        <span v-show="errors.has('email', 'sign_up')">{{ errors.first('email', 'sign_up') }}</span>

        <button type="button" @click="validate('sign_up')">Validate</button>
    </form>
    <br><br>
    <form data-scope="login">
        <input type="text" name="email" v-validate data-rules="required|email">
        <span v-show="errors.has('email', 'login')">{{ errors.first('email', 'login') }}</span>

        <button type="button" @click="validate('login')">Validate</button>
    </form>
</div>

as you can see, most ErrorBag methods now allows an additional optional parameter to focus on a specific scope. any and clear and remove methods also have this additional parameter.

In addition to this, you can also trigger validation on all fields within a specific scope, using validator.validateAll which now accepts the name of the scope as a string. The following JS code completes the previous html:

Vue.use(VeeValidate);

new Vue({
    el: '#app',
    methods: {
        validate(scope) {
            this.$validator.validateAll(scope);
        }
    }
});

A working example can be found here.

What else? some embarrassing bugs have been fixed. and some amazing people added new languages to the plugin, many thanks for each one of them.

1.0.0-beta.4

Latest tag broke field dependent rules like confirmed and after and before due to the addition of scopes. should be fixed now.

Scopes

Previously the validator instance had only one scope, the same scope as its owning Vue instance. so duplicate fields would conflict if they had the same name. one way to avoid conflict was to give them different names and give them the same display name. but if you had two forms within the same component and you wanted to display each form errors independently from each other that would be hard to do.

This new release offers scopes to handle this issue, you would give the fields a scope then you can provide a scope to the ErrorBag object methods, so it can locate those errors even if duplicate fields exists across different scopes. this can be done by providing a data-scope attribute on the field or on the form that contains the field.

here is a small example:

HTML:

<form data-scope="sign_up">
    <input type="text" name="email" v-validate data-rules="required|email">
    <span v-show="errors.has('email', 'sign_up')">{{ errors.first('email', 'sign_up') }}</span>

    <button type="button" @click="validate('sign_up')">Validate</button>
</form>
<br><br>
<form data-scope="login">
    <input type="text" name="email" v-validate data-rules="required|email">
    <span v-show="errors.has('email', 'login')">{{ errors.first('email', 'login') }}</span>

    <button type="button" @click="validate('login')">Validate</button>
</form>

as you can see, most ErrorBag methods now allows an additional optional parameter to focus on a specific scope. any and clear and remove methods also have this additional parameter.

In addition to this, you can also trigger validation on all fields within a specific scope, using validator.validateAll which now accepts the name of the scope as a string. The following JS code completes the previous html:

Vue.use(VeeValidate);

new Vue({
    el: 'body',
    methods: {
        validate(scope) {
            this.$validator.validateAll(scope);
        }
    }
});

A working example can be found here.

What else? some embarrassing bugs have been fixed. and some amazing people added new languages to the plugin, many thanks for each one of them.

1.0.0-beta.2

Fix issue caused by the 1.0.0-beta releases that prevented the confirmed and after and before rules from attaching the extra listener for the target field.

Thanks for Michalis Rousos for pointing out this issue.

2.0.0-beta.7

Important Changes:

As mentioned here #10 The required rule was misleading in the previous releases, it implied that the fields that are not required should pass the validation if they had empty values and that is indeed the intended behavior. However that wasn't the case, some fields passed, some didn't depending on how each validates empty values.

This release fixes that behavior. From now on, all fields that do not have the required rule will pass the validation if they have empty values. Those empty values are: null, undefined and ''. if a non-empty value was provided it will proceed to validate them as before.

1.0.0-beta.1

Important Changes:

As mentioned here #10 The required rule was misleading in the previous releases, it implied that the fields that are not required should pass the validation if they had empty values and that is indeed the intended behavior. However that wasn't the case, some fields passed, some didn't depending on how each validates empty values.

This release fixes that behavior. From now on, all fields that do not have the required rule will pass the validation if they have empty values. Those empty values are: null, undefined and ''. if a non-empty value was provided it will proceed to validate them as before.

Bind on nextTick

As described here #9 the Vue 1.x dist wasn't detecting the bound values due to the directive hooks getting called before the DOM update cycle. It is delayed now until the nextTick so your bound values are updated. which is useful if you are creating some sort of a component that validates itself.

Note: This however is only working for initial rendering, the validator still caches the rules and will ignore any changes to the attributes its using data-as and data-rules. so you shouldn't mutate them dynamically.

Dictionaries and Attributes

Changes:

• Rework how messages are stored within the validator, now there is a new Dictionary class involved which contains the messages generators and the attributes object.
• validator.validate or validator.validateAll will now return Promise if at least one validation result is a Promise.
• Fix an issue when passing a configuration when installing the plugin.

Breaking Changes:

• validator.updateDictionary(dictionary) will accept a different dictionary structure than before to accommodate for the attributes object which was mentioned here #8

Here is what the new dictionary will look like:

const dictionary = {
    en: {
        messages: { ... },    // Your messages to overwrite the default English messages.
        attributes: {    //  Your custom attributes (names) for each field.
            email: 'Email Address',
            // ...
        }   
    },
    ar: {
      messages: { ... },
      attributes: { ... }
    }
};

validator.updateDictionary(dictionary);

The attributes object is not required, it is helpful if you want to display customized names in the error messages. which is surely better than using data-as attribute on each field in your html.

However data-as still takes precedence over the name defined in attributes. The docs were updated with the new details.

This structure will allow flexibility with the contents of the dictionaries in the future.

Dictionaries and Attributes

Changes:

• Rework how messages are stored within the validator, now there is a new Dictionary class involved which contains the messages generators and the attributes object.
• validator.validate or validator.validateAll will now return Promise if at least one validation result is a Promise.
• Fix an issue when passing a configuration when installing the plugin.

Breaking Changes:

• validator.updateDictionary(dictionary) will accept a different dictionary structure than before to accommodate for the attributes object which was mentioned here #8

Here is what the new dictionary will look like:

const dictionary = {
    en: {
        messages: { ... },    // Your messages to overwrite the default English messages.
        attributes: {    //  Your custom attributes (names) for each field.
            email: 'Email Address',
            // ...
        }   
    },
    ar: {
      messages: { ... },
      attributes: { ... }
    }
};

validator.updateDictionary(dictionary);

The attributes object is not required, it is helpful if you want to display customized names in the error messages. which is surely better than using data-as attribute on each field in your html.

However data-as still takes precedence over the name defined in attributes. The docs were updated with the new details.

This structure will allow flexibility with the contents of the dictionaries in the future.

Date Validations

Date validations are now available as those rules:

• date_format:{format} validates that the field under validation must have a valid date according to the provided format.
• after:{target} validates that the field under validation must have a valid date and is after the target input date value.
• before:{target} validates that the field under validation must have a valid date and is before the target input date value.
• date_between:{min,max} validates that the field under validation must have a valid date that is between the min date and the maximum date.

These validators require momentjs in order to work, you have to call validator.installDateTimeValidators(moment) and pass momentjs reference to install the validators, they are installed automatically if you have it referenced globally.

All date rules above require date_format rule to be present, since validations occur from left to right, date_format must exist before any of the other date rules. This is because it is recommended by momentjs to parse all dates with specific formats to avoid errors as much as possible. the parsing mode is always strict to further reduce parsing errors, and ultimately validation false-positives.

Strict Mode

The validators now operate by default in strict mode, which when validating non-attached fields returns false. you can turn it off using $validator.setStrictMode(false) which will turn it off for the validator instance or Validator.setStrictMode(false) to turn it off for all newly created validators.

Many thanks for:

• @gig3m for identifying and helping fix a critical issue, also for implementing strict mode.
• @hootlex for fixing a dead link in the docs.