Hello guys,
After https://github.com/monterail/vuelidate/issues/3 is implemented, an Error Component would be really cool.
It can have for, rule, and amount properties. For example:
// display the first 2 errors for 'name'
<vuelidate-error :for="name" amount="2"><vuelidate-error>
// display the error for the 'required' rule
<vuelidate-error :for="email" rule="required"><vuelidate-error>
// display the errors for a group
<vuelidate-error :for="groupOne"><vuelidate-error>
For starters, it can return a plain text in order to let devs wrap it within other tags.
<p class="text-danger">
<vuelidate-error :for="groupOne"><vuelidate-error>
</p>
Later on, we can make it templatable but I don't know yet if this will be handy.
<vuelidate-error :for="email" template="bootstrap"><vuelidate-error>
<vuelidate-error :for="email" template="semantic"><vuelidate-error>
<vuelidate-error :for="email" template="plain"><vuelidate-error>
// or by passing 'class names'
<vuelidate-error :for="email" classes="['text-danger', 'whoops']"><vuelidate-error>
What do you think?
As much as I like the idea of components for that in certain use cases, I'm not sure it should be a part of the library. Pretty much anybody has slightly different requirements, so creating a needlessly complex generic beast to support all of them is not a way to go in my opinion. That's also the reasoning behind leaving event binding up to the developer. We work only with data.
But I like it nevertheless. What do you think about creating a set of documented examples how such a simple component can be done and leave any needed modifications up to the developer again?
Maybe we should add a cookbook with some examples for more complex validations w/ error components the roadmap?
@Frizi I agree that this would make the plugin huge for no reason since only a few devs will use the component. Creating a set of documented examples sounds nice.
Creating another module, vuelidate-error for example, which will provide the abovementioned features might also be handy.
Most helpful comment
As much as I like the idea of components for that in certain use cases, I'm not sure it should be a part of the library. Pretty much anybody has slightly different requirements, so creating a needlessly complex generic beast to support all of them is not a way to go in my opinion. That's also the reasoning behind leaving event binding up to the developer. We work only with data.
But I like it nevertheless. What do you think about creating a set of documented examples how such a simple component can be done and leave any needed modifications up to the developer again?