dobromir-hristov / vuelidate-error-extractor

Vuelidate form-group helper that extracts errors easily.
https://dobromir-hristov.github.io/vuelidate-error-extractor/
MIT License
138 stars 15 forks source link

Template free usage #26

Open cmeyertons opened 5 years ago

cmeyertons commented 5 years ago

Have a feature request?

Hi there! Great library, solving a very common problem with validate in general as there tends to be validation message "sprawl".

Currently using Vuetify and I tried out the Vuetify example and the passing of :validator into the template felt a little dirty (I feel like it's making the template too smart).

I guess what would be useful is a way to leverage the message generating "smarts" of this library w/o tying it to the view.

What I initially tried was:

<template>
<v-text-field
              name="first-name"
              :placeholder="$t('First name')"
              v-model.trim="personalDetails.firstName"
              @blur="$v.personalDetails.firstName.$touch()"
              autocomplete="given-name"
              :error-messages="firstNameErrors"
            />
</template>
<script>
import Vue from 'vue'
import { singleErrorExtractorMixin } from 'vuelidate-error-extractor'

import { required, minLength, email, sameAs } from 'vuelidate/lib/validators'
export default {
  mixins: [ singleErrorExtractorMixin ]
  validations: {
    personalDetails: {
      firstName: { required, minLength: minLength(3 }
  },
  computed: {
    firstNameErrors () {
      return this.getErrorMessage('personalDetails.firstName')
    },
  }
})
</script>

But all the VEE stuff is essentially dead, because I haven't wired it up to the view. I was expecting VEE to watch the current components $v and update itself accordingly.

So here, ideally, I have a mixin method exposed that just looks at $v and massages an error message out based on the property I'm asking for.

dobromir-hristov commented 5 years ago

Why do you want to mix the extractor into each component like that? You are then mixing extraction logic into your other form components. You can use the validation extractors just as providers, using scoped slots to pass down that is needed to the child components.

The vuetify example is literally that, a data provided that passes data to it's children. This is a standard way to work with data, when using component based frameworks.

cmeyertons commented 5 years ago

I guess in my initial implementation, I didn't initially realize the extractor mixins already had a validator in context that scoped them down to one property in the model.

So maybe it would be a separate mixin vs the one you have (I would call the current one an extractor-template-mixin)

Not every component needs form validation? I can pick and choose which ones get the extractor logic or if I desire define it as a global mixin?

I'm having to write appx the same amount of code, but instead of having a "magic" wrapper component that binds the error message accordingly and passes it down to the vuetify component, the code is much more explicit and easy to understand in a computed property.

This usage leans the library down to a pure error message generator w/ vuelidate smarts vs an error message + wrapper template library, keeping my template code leaner.

Another thing I saw out of the box w/ the example was the form-group messed up the width of the underlying component, but that's probably just some CSS i need to solve.

dobromir-hristov commented 5 years ago

Well, there are many ways to do it, this library uses the traditional component based approach, as error messages are tied to the template, not your business logic.

Sorry if it's not working for you.

Adding a generic helper to extract errors is possible, but will require some configuration, like passing the name or label of the field you are extracting for, otherwise error messages are very generic.

cmeyertons commented 5 years ago

No worries! Yeah if you see my example up there, it's passing in basically what you would give the :validator binding anyways.

Just thought it would be useful to have a template-free hook into the extremely valuable logic of this lib.

If you don't agree, I don't probably have the time to take it on myself so you can close if desired. Appreciate you taking the time to discuss!