-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(form): errorMessages should be reactive #15188
Conversation
If you have an input without rules then form.valid is never true: <template>
<v-app>
<v-container>
<v-form ref="form" v-slot="{ errorMessages }" v-model="valid" @submit.prevent>
<v-text-field :rules="rules" />
<v-text-field :rules="rules" />
<v-text-field />
<pre>{{ { valid, errorMessages } }}</pre>
<v-btn type="submit">Validate</v-btn>
</v-form>
</v-container>
</v-app>
</template>
<script setup lang="ts">
import { ref } from 'vue'
import { VForm } from '../src/components'
const rules = [
v => !!v || 'Required',
v => v.length < 5 || 'More than 5',
]
const form = ref<VForm>()
const valid = ref<boolean>(false)
</script> |
Not sure how we want form to work. With your example, form should of course validate to true if first two inputs have valid inputs. But without writing anything in third field, should it do it "on the fly", or just when explicitly calling validate?
|
You don't always use reactive error messages, you still get errors under form elements. |
No reason it shouldn't always be available though.
Yeah if there's no rules (or error-messages) it's always valid. v2 also had the ability to specify if you want all rules to contribute to isValid (default), or only rules from dirty fields (lay-validation). |
bd54e69
to
6c34ccb
Compare
c62375c
to
c692f92
Compare
d15d2f2
to
9f20ac1
Compare
6632d14
to
acfc3c4
Compare
Description
Alternative solution to #15140
Here
errorMessages
is always reactive. Not sure if there are scenarios where you'd want the previous behaviour?Motivation and Context
How Has This Been Tested?
Markup:
Types of changes
Checklist:
master
for bug fixes and documentation updates,dev
for new features and backwards compatible changes andnext
for non-backwards compatible changes).