Open cmeyertons opened 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.
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.
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.
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!
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:
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.