Releases: logaretm/vee-validate
v4.10.8
v4.10.7
v4.10.6
✨ Behavior Changes
This is because it was causing modal forms to have errors on mounted which confused users. This does not effectively change anything other than you will no longer need to reset the form whenever the modal is shown or when the fields are mounted. If you relied on this behavior then it could be a breaking change for you and you can get it back by enabling validateOnMount
or calling validate
whenever.
This does not affect initial errors or validateOnMount
option.
🐛 Bug Fixes
- resetForm should cast typed schema values closes #4347 (e9b215a)
- validate form values on setValues by default closes #4359 (4e11ff9)
- normalize error paths to use brackets for indices closes #4211 (e354a13)
⚙️ Misc
v4.10.5
v4.10.4
v4.10.3
🐛 Bug Fixes
- SSR: Avoid referencing window with
setTimeout
for validation batching #4339 (#4340) thanks to @userquin 🙌 - Respect model modifiers when emitting the value with
useField
v-model integration #4333 (c3698f0)
✨ Enhancements
Made object dirty
meta checks less strict by treating undefined and missing keys as the same value #4338 (32537e1)
This may cause some differences with the value of dirty
meta for forms and object value fields but it shouldn't affect most cases.
v4.10.2
v4.10.1
v4.10.0
💣 Breaking Change
Disabled syncVModel
by default #4283 (7ce9d67)
A lot of issues created because of this and valid issues and concerns by the community caused by useField
auto model tracking causing unexpected behavior for a lot of people. The feature has been disabled by default starting from v4.10.0
.
If you relied on useField
doing auto modelValue
and update:modelValue
emitting then you need to turn it on by passing true
to syncVModel
.
const { ... } = useField('name', undefined, {
syncVModel: true,
});
Check the discussion in #4283
This makes sense, because it being opt-in makes it less dangerous to cause unexpected behavior.
useForm#values
is now readonly #4282 (05d957e)
the values
object returned from useForm
should have never been treated as mutable and the docs mentioned that a few times and didn't encourage it.
In this release, we mark it as readonly
to make it clear to everyone that it should not be mutated directly. The main reason for this design choice is we need to be able to infer the user intent with those mutations. For example, if you clear an array, did you mean to reset the field or did you mean to change its value and trigger a validation?
Being able to infer the user intent is paramount for vee-validate to be able to handle such behaviors correctly, it has always been the case here, and marking it as readonly
is just a hint that should've been there from the start.
This should not affect a lot of users.
💅 DX enhancements
- Allow custom models for defineComponentBinds (bfd6b00)
handleBlur
can be configured to run validations (d4fafc9)useField#syncVModel
also accepts the model prop name (3e4a7c1)- Allow multiple messages to be returned in a validator function #4322 #4318 (2cf0eec)
🐛 Bug Fixes
resetForm
should merge values #4320 (77345c4)- Use event value if no checked value for checkbox/radio #4308 (f1dc135)
- Trigger validation with setFieldValue by default #4314 (ed20891)
- Parse native number fields #4313 (6a3f9f1)
👕 TypeScript
vee-validate v4.10.0
requires [email protected]
as it uses many of the newly introduced types to replace its own version of them, this should not affect your experience however it may produce type errors if you relied on some of these internal types. Like MaybeRefOrLazy
replaced with MaybeRefOrGetter
.
v4.9.6
🐛 Bug Fixes
- Field's
handleBlur
should respectvalidateOnBlur
config #4285 (6e074f7) - Correctly merge non-plain objects in form's
setValues
#4287 (#4289) thanks to @VladStepanov
👕 TypeScript
- Improve Field binding types (#4291) thanks to @FedorSherbakov
- export
SetFieldValueOptions
interface #4290 (b138282)