Skip to content
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

Template free usage #26

Open
cmeyertons opened this issue Apr 30, 2019 · 4 comments
Open

Template free usage #26

cmeyertons opened this issue Apr 30, 2019 · 4 comments

Comments

@cmeyertons
Copy link

cmeyertons commented Apr 30, 2019

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
Copy link
Owner

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
Copy link
Author

cmeyertons commented May 1, 2019

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
Copy link
Owner

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
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants