I started with it. But it doesn't play fair with typescript. Issues filed on the repo and PRs submitted as solutions but the repo owners also didn't meet devs halfway. On top of that, the site that introduced me to VeeValidate had a section after its intro that rants about the latter. Here just scroll to the last section.
Read the rant, he does have a point but I feel like also TypeScript can be a burden on maintainers that don't know/use/like it. He should have probably accepted the patch after making sure that the contributor was available on maintaining TS support from then on.
It's always tricky. Everytime you accept a big patch you're also going to maintain it in the future. If you fork a project like this because of the lack of a "small" feature, you're also going to need to keep it in sync, updating the types definition everytime there's something new.
I use both VeeValidate and Vuelidate on several production apps. I love that Vuelidate is model-based and not DOM-based... But it's significantly harder to use for more complex things. The documentation for anything past the basics is utterly worthless and they keep changing validators so that, apps that worked just fine in the past, now fail validations all over the place if updated because of changed behavior.
Because of this, I've mostly converted back to VeeValidate. I'd prefer to stick with Vuelidate, as its API makes more sense IMO and it's ridiculously simple to add custom validations to... But inconsistencies in functionality and the fact that writing conditional validations can be an utter mess has me saying away from it. I wish there were more good options out there, honestly.
I don't agree entirely but I can understand your frustration.
Lately though I'm thinking more about the cost of open source from all sides. Vuelidate is a perfectly fine library and as you say, its API is nice and users can use it easily. But it has limitations, because it's aimed at simple scenarios that can be mapped on top of it. If you want full control you'll end up looking for alternatives.
This doesn't make VueValidate bad, it just makes it geared to some cases but not all. At the same time as you said you have VeeValidate which is more complicated to use but can scale a little better than Vuelidate. Unfortunately it's also massive in size.
I wish there were more good options out there, honestly.
Definitely, or maybe VeeValidate needs to be split up in plugins? Don't know, just an idea.
The issue with custom tailored validation logic (reminds me of the hacks on top of jQuery back in the day :D) is that it doesn't scale as in: it will get complicated quickly, especially if your validation is complex (and mine was, that's why I had to leave Vuelidate for VeeValidate) or if you don't want to start from scratch everytime you start a new app.
I'm not saying your case should use a library, but that a library has its purposes.
Again, there's no perfect solution :D
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You can also use vuelidate which is good enough for most cases an smaller than veevalidate...
I started with it. But it doesn't play fair with typescript. Issues filed on the repo and PRs submitted as solutions but the repo owners also didn't meet devs halfway. On top of that, the site that introduced me to VeeValidate had a section after its intro that rants about the latter. Here just scroll to the last section.
Read the rant, he does have a point but I feel like also TypeScript can be a burden on maintainers that don't know/use/like it. He should have probably accepted the patch after making sure that the contributor was available on maintaining TS support from then on.
Very true. I wonder if anyone cared to fork the project just for typescript intergation 🤔
It's always tricky. Everytime you accept a big patch you're also going to maintain it in the future. If you fork a project like this because of the lack of a "small" feature, you're also going to need to keep it in sync, updating the types definition everytime there's something new.
There's no perfect solution
I use both VeeValidate and Vuelidate on several production apps. I love that Vuelidate is model-based and not DOM-based... But it's significantly harder to use for more complex things. The documentation for anything past the basics is utterly worthless and they keep changing validators so that, apps that worked just fine in the past, now fail validations all over the place if updated because of changed behavior.
Because of this, I've mostly converted back to VeeValidate. I'd prefer to stick with Vuelidate, as its API makes more sense IMO and it's ridiculously simple to add custom validations to... But inconsistencies in functionality and the fact that writing conditional validations can be an utter mess has me saying away from it. I wish there were more good options out there, honestly.
After trying both for my side project. I ended up with just this
A little bit more work but I believe it's worth it
I don't agree entirely but I can understand your frustration.
Lately though I'm thinking more about the cost of open source from all sides. Vuelidate is a perfectly fine library and as you say, its API is nice and users can use it easily. But it has limitations, because it's aimed at simple scenarios that can be mapped on top of it. If you want full control you'll end up looking for alternatives.
This doesn't make VueValidate bad, it just makes it geared to some cases but not all. At the same time as you said you have VeeValidate which is more complicated to use but can scale a little better than Vuelidate. Unfortunately it's also massive in size.
Definitely, or maybe VeeValidate needs to be split up in plugins? Don't know, just an idea.
The issue with custom tailored validation logic (reminds me of the hacks on top of jQuery back in the day :D) is that it doesn't scale as in: it will get complicated quickly, especially if your validation is complex (and mine was, that's why I had to leave Vuelidate for VeeValidate) or if you don't want to start from scratch everytime you start a new app.
I'm not saying your case should use a library, but that a library has its purposes.
Again, there's no perfect solution :D