2.0.0-rc.10

🐛 Fixed

• Fixed an issue where field dependency tracking was broken which prevented rules like confirmed from working properly. #712 #716

• Fixed an issue for rules change detection which prevented rules like regex from updating correctly. #710

• Fixed an issue that allowed delayed (debounced) validations to run just before component destruction which was apparent with vue-router. #709

Aside from that, there are also locale updates thanks to the awesome contributions.

2.0.0-rc.9

🐛 Fixes

• Fix an issue that prevented automatic classes from working. #680
• Fix an issue where a falsy (like empty strings) rules would crash field initialization. #676
• Fix an issue where disable modifier did not have an effect. #681
• Fix before and after inclusion parameter that was ignored after recent changes to the pipeline. #683 thanks @rafi1978
• Fix an issue when adding listeners for radio buttons and checkboxes groups because NodeList does not contain a forEach method. #686
• Fix an issue that prevented disabled fields from being matched by the field query when validating a field #698
• Fix failure to detect scopes for some scoped custom components. #699
• Fix an issue with element-ui that caused an infinite loop. #696
• Fix checkboxes not rejecting the false value when bound by v-model.

💯 Enhancements

• Set the custom validity for native HTML fields, which allows you to target their css styling with psudo :valid and :invalid selectors. #671
• The validator now validates the field after its rules change, this only happens if the field was validated previously either manually or by user input.
• Updated type definitions #691 Thanks @agentschmitt
• Checkboxes and Radio buttons do not emit a blur event on Mac, instead they will set their untouched and touched flags on click instead.
• Validate method has been overloaded to support multiple usecases and to eliminate confusion with other methods, here is all the behavior supported by the validate method:

// No args, validates all fields regardless of scope.
validator.validate();

// '*' as the sole arg, validates all scopeless fields.
validator.validate('*');

// validate a specific scope
validator.validate('myScope.*');

// validates a specific field by id (used internally).
validator.validate('#fieldId');

// validates a specific field by name.
validator.validate('field');


// validates a scoped field (also a field with a dot in its name as a fallback):
validator.validate('scope.field');

This allows you to use the validate method as the primary way to validate fields and eliminates some confusion between validateAll and validateScopes since in time they will be less mentioned and used as examples, however they are not deprecated and will continually be exposed as a public API.

2.0.0-rc.8

This release does not contain any major breaking changes, and the validation pipeline and structure has been rewritten.

🐛 Fixed

• Fixed issues that caused the validator no to detect inputs when being inserted in a slot #631.
• Fixed issue that prevented validateAll from detecting input values when executed for the first time.
• Added $attrs detection as a fallback if the component has inheritAttrs set to false (Vuetify) #653 #651.
• Some Issues with early exit has been resolved #660 Thanks @OmerZfira
• Fixed an issue where detached fields using v-if or v-for would still have their messages stuck in the errorBag.
• Fixed an issue where field alias using data-vv-as detection was unreliable with custom components.
• Fixed a long standing issue where the component had a name attribute but wasn't added as a prop (only works in Vue 2.4).

✨ Enhancements

New way to identify fields (Internal):

Most problems originated from not being able to identify a field correctly during the life cycle of the components because the name and the scope of a field are not enough to identify it correctly at any given moment. So fields have been given a unique id to be the main way to identify fields internally.

You don't have to change anything as this is not a breaking change, but if you were using the validator manually you should take the following into consideration:

The attach method now accepts an object as its only parameter, and returns a field object which can be later used to validate the field using its id.

const field = validator.attach(options); // add the field.
validator.validate('#' + field.id); // validate the field by id, no need to pass the value as it will be resolved.

The old signatures are still being supported, but it is recommended that you switch to the new API, before futurue deprecation.

Field Targeting.

Added the ability to provide custom selectors when targeting target fields for confirmed, after, and before rules, which now support using a selector or a Vue ref which allows to target a component:

• confirmed:$pass tries to resolve a field that is registered in $refs of the context component. (recommended)
• confirmed:#pass Tries to resolve a field which its id is pass.
• confirmed:.pass tries to resolve a field which has a pass class.
• confirmed:pass Tries to resolve a field which its name is pass.

Note that selectors will only look inside the context vm template, and will not expand to the entire DOM nor the parent components, so make sure to keep your related inputs within the same component. Here is an example for custom components.

General

• touched and untouched flags are now set on blur instead of focus to match behavior already established by other libraries.
• Calling validate without any parameters is the same as calling validateAll.
• Most built in rules have been updated to be able to work with arrays, if you pass an array as a value each item will be validated against the pipeline.

Minor Changes

General

Few internal property names has been updated, while these changes can be breaking for some rare cases:

• ErrorBag.errors property will be renamed to items since errors.errors feels silly 🥇.
• Validator.errorBag property will be renamed to Validator.errors.
• EnableAutoClasses option has been renamed to classes.

Deprecated Methods ❗️

• Validator's instance append method has been deprecated.
• Validator's instance updateField method has been deprecated.
• Validator's instance attach method signature was updated, it now accepts a field options object, it still supports the old signature but you should switch to the new signature after merge.
• Some Validator's internal API methods have been deprecated, they were not designed to be called by users anyways.
• reject modifier has been deprecated since it should be the responsibility of the app to decide what to do after failed validation.
• ErrorBag's add method signature now accepts an object as its sole parameter, the object should contain the field, msg, rule and scope attributes that were previously passed in as parameters, in addition to id property which is the field id.

2.0.0-rc.7

🐛 Fixed

• Fix field scope detection after rc.6 change in directive lifecycle hooks.
• Fix target based (after, confirmed, before) rules ignoring the custom names set in attributes dictionary #598
• Fix radio buttons validation with validateAll #609
• Fix ambiguous error reporting #619
• Fix improper validation where fastExit is enabled #607

Enhancements ✨

• Checkboxes now have a special interaction with the required rule, as false is considered an empty value, for other input types false is a perfectly valid value #613.
• Promise based validations are no longer required to return an object containing valid property, they can now return booleans directly #608.
• date_format can now be provided in the dictionary object, removing the need to pass it everytime you use a date rule #576.

import { Validator } from 'vee-validate';

Validator.dictionary.setDateFormat('locale', 'format');

// Your locale files can also contain `dateFormat` attribute as a root property in the locale object.
const fr = {
  messages: {},
  attributes: {},
  custom: {},
  dateFormat: 'format'
};

// then you can use `updateDictionary` method to merge your locale in
Validator.updateDictionary({ fr });

2.0.0-rc.6

Breaking Changes 💥

As pointed out here #507 by @rstuart85 While the catch behavior was suitable for people who always intended to have a catch handler, but was verbose for the people who didn't. And also it caused other issues or exceptions to be reported as a validation error which isn't the case.

The validateAll, validate and validateScopes has been changed to return a Promise that will always resolve regardless of the validation status, the resolved value will be either true or false depending on the validation status, which takes us back to pre beta.18.

So the catch handler will now run only when something critical has gone wrong, like a custom validator failure, or actual bugs.

this.$validator.validateAll().then(result => {
  if (! result) {
    // handle input errors.
    return;
  }

  // submit the form or whatever.
}).catch(() => {
  // this is an actual app logic error.
});

Fixed 🐛

• Error Bag uses splicing instead of re-assignment to reduce the bugs resulted from re-rendering the DOM which caused some inputs to be unresponsive to user input, thanks @ThomHurks for #569

• Fix issue with flags not refreshed after a data change on custom components, thanks @Toilal for #580

• Fix validator API method flag not setting flags for fields with dots in their name correctly. #567

• Fix an issue with computed properties validation where the validator will validate the input value instead of the actual computed value #423.

• Fixed an issue where unwatchable models with lazy modifier would lock up the input from being used, fixed by listening using the change listener to be consistent with the lazy modifier behavior.

• Fix context and getter pairs generation for bound fields and custom components. #521

• Use the bind hook to setup the validation on the field, previously it was using inserted which fixes binding inside transitions or templates. #496

• Fix debounced validation running immediately at all times. #519

Enhancements ✨

• Type definitions for the pending and the required flags have been added thanks to @agentschmitt for #571

• Added a new validated flag which reflects the validation status of the input, by default it is false until the field has been validated at least once, previously it was being achieved by checking the valid and invalid properties if they are equal to null or not.

• The ValidatorException now properly extends the native Error class which means better error reporting and stack traces will be reported.

• Inputs that are disabled will now be ignored during validation or using the manual API, components can similarly have a disabled attribute which will behave in the same way. #245

• Extending the validator with custom rules will no longer throw an exception if the rule already exists, it will overwrite it silently.

• before and after messages have been adjusted to include the inclusion case. other locales might need your help.

• The ES6 module version has been renamed to vee-validate.esm.js

Thank you so much for the locale maintainers for the nice PRs submitted this month.

2.0.0-rc.5

⚠️ This addresses critical issue that caused fields bound by v-model didn't validate properly.

Fix #515 and #516

2.0.0-rc.4

⚠️ The library now expects a Vue version >= 2.2.0 in order for all features to work correctly. ⚠️

Fixed 🐛

• Fix an issue when validator fails upon attaching fields with dots in their name #462.
• Fix an issue when debouncing with 0ms caused unintended asynchronous behavior #376.

Enhancements 🛠

• Added false to the list of empty values for the required rule (useful for checkboxes).
• You can now globally set the events you are interested in for validation, by setting the events option:

Vue.use(VeeValidate, {
    events: 'input|blur' // default value.
});

⚠️ Note that this feature currently only works for native inputs, components are excluded from this behavior.

• Errors Messages can also be strings now instead of functions, which should make JSON lang files possible.
• Added clean method to the validator object which clears the errorBag in the next tick, which helps you clear the errors after form resets.

this.$validator.clean();

If you are using the validator object standalone without an associated component, then it would call errors.clear() immediately.

New Stuff ✨

Parent Injections #468

If you ever needed to use the validator on specific inputs, or share validator instance and errorBag instances, you previously had to communicate the errors via an event bus or similar approaches. The library now takes advantage of Vue's Provide/Inject API Which enables you to inject the parent's validator instance along with the errorBag and the fieldBag instances.

To Inject the parent component validator you need to request $validator in your injections:

export default {
    inject: ['$validator']
};

// or

export default {
   inject: {
        $validator: '$validator'
   }
};

Otherwise the plugin will create a new validator for that component if it doesn't inject from the parent.

Furthermore, you might want to disable autmatic injection of validators and control which component injects the validator and which gets a new one. To enable this behavior you must first disable the automatic injection by setting the inject option to false when installing the plugin:

Vue.use(VeeValidate, {
    inject: false // turn off automatic injection.
});

This stops the plugin from creating a validator instance for each component, which maybe desired when using third party libraries that may conflict with the library injections.

Note: The errorBag and the fieldBag objects are only injected if your component have a validator instance, regardless how your component got it. Also if you try to use the directive in a component that does not have a validator instance it will display a warning.

Thanks for @alpaelf i for providing great feedback and discussion for this feature.

Custom Field Messages #490

You might need to provide different messages for different fields, for example you might want to display an error message for the email field when its required, but a different message when the name is required. This allows you to give your users a flexible experience and context aware messages.

To do this you would need to add an object to the dictionary called custom like this:

const dict = {
  en: {
    custom: {
      email: {
        required: 'Your email is empty'
      },
      name: {
        required: () => 'Your name is empty'
      }
    }
  }
};

Then you would need to add the dictionary we just constructed to the current validators dictionary like this:

Validator.updateDictionary(dict);
// or use the instance method
this.$validator.updateDictionary(dict);

Any unspecified rules will fallback to their uncustomized error messages.

As always, many thanks for all those who updated the locale files and who opened issues to make this library better, you guys are awesome 💯

2.0.0-rc.3

Fix npm package not including the Locales

2.0.0-rc.2

This contains fixes for critical issues:

• Fix v-model watcher not setup correctly #454.
• Fix scoped flags overwriting/removing other fields objects.

2.0.0-rc.1

After a long time since the last release, a lot of issues has been addressed and much more needed improvements are added, also I'm happy to say the first release candidate as I'm confident with the current API and would like to continue along with it.

Breaking Changes 🔥

• .initial modifier now forces validation on the initial value instead of ignoring it, by default initial values will be ignored. previously it was supposed to ignore the initial value but the modifier had not effect.

• Custom components validation, you now won't need to provide a data-vv-value-path attribute, instead the validator will expect a value property on the component that is watchable via the $watch API.

• validator.getLocale() is deprecated in favor of locale getter.

• The flags API has deprecated, this change is needed because the previous API was fragile and hard to extend without changing a lot, however the flags are now accessed like regular objects, and they are now reactive, meaning you can use them in your computed properties.

Here is an example of how you would use the new flags API:

    <div class="form-input">
      <input type="text" name="field" v-validate="'required|email'" placeholder="Field">
      <span v-show="errors.has('field')">{{ errors.first('field') }}</span>
      <span v-show="fields.field && fields.field.dirty">I'm Dirty</span>
      <span v-show="fields.field && fields.field.touched">I'm touched</span>
      <span v-show="fields.field && fields.field.valid">I'm valid</span>
    </div>

Notice that you need to check for the field existence before attempting to access the flags, that is to avoid component rendering errors since the flags objects are only available after the mounted() cycle.

Also flags now support scopes, for global level fields' flags, they will be available on the root flag object:

const isDirty = this.fields.email.dirty;

For scoped fields, their flags will be available in a property prefixed with $ to differentiate between a global level field and a scope:

const isDirty = this.fields.$scope.email.dirty;

For convenience a helper function mapFields was added to skip these checks, it maps the fields flags to the component computed property, so you would need to specify which fields you need mapped, it is similar to Vuex's mapGetters and mapActions helper functions:

<script>
import { mapFields } from 'vee-validate'

export default {
  // ...
  computed: mapFields(['name', 'email', 'scope.phone']),
 // ...
}
</script>

You can also use the object form to rename the mapped props:

<script>
import { mapFields } from 'vee-validate'

export default {
  // ...
  computed: mapFields({
    fullname: 'name',
    phone: 'scope.phone'
  }),
 // ...
}
</script>

Note that scoped fields names in the array from is mapped to a non-nested name. and you can use the object spread operator to add the mapped fields to your existing computed components:

<script>
import { mapFields } from 'vee-validate'

export default {
  // ...
  computed: {
    ...mapFields(['name', 'email', 'scope.phone']),
    myProp() {
       // ....
    }
  },
 // ...
}
</script>

The available flags are:

• touched: The field has been focused at least once.
• untouched: The field has not been focused at all.
• dirty: The field value has been manipulated (even if it is the same).
• pristine: The field has not been manipulated.
• valid: The field has been validated at least once and is valid.
• invalid The field has been validated at least once and is not valid.

You can set the flags using the flag method on the validator instance:

// flag the field as valid and dirty.
validator.flag('field', {
  valid: false,
  dirty: true
});

// set flags for scoped field.
validator.flag('scoped.field', {
  touched: false,
  dirty: false
});

For custom components, in order for the flags to fully work reliably, you need to emit those events:

The input event, which you probably already emit, will set the dirty and pristine flags.

this.$emit('input', value); 

The focus event which will set the touched and untouched flags.

this.$emit('focus'); 

Improvements 👏

• The new .disable modifier halts all listening behavior for the validator. which was needed if you only want to trigger validation on demand instead of automatic, for example when a form is submitted.

• The after and before rules now accept an inclusion flag as the second parameter, which allows the target equal date values to be valid as well. to enable it just pass any value as a second parameter.

after:target,true

• The after and before rules now accept a date value as an alternative to the field name, note that the date must be written in the same format as the preceding date_format rule.

• The rules with target field arguments like confirmed now respects the events you have specified using data-vv-validate-on attribute.

• You can access the rules and dictionary objects via the read only properties on the validator instance.

• The date_between rule also accepts moment's inclusive parameters #419

Bugs Squashed 🐛

• The automatic class bindings now have their own listeners meaning they will be in sync with the flags. however they are not tied to the error object, meaning if you add custom errors you will have to invalidate the flags yourself using the API.

• Can't remember the rest of the bugs, but plenty were fixed. I need to be better organized 😞.

Docs State

I will update the docs this week, so not all of the mentioned things will be updated there at least for a few days.