pablo-abc
Any reason why there is no validator-cvapi?
Hey,
just played with felte and had to ask myself the question if there is any reason I don't see, why there is no validator-cvapi?
Imho it could be lightweight validator for simple forms (like login f.e.) with built-in i18n. Most of the shortcomings of the cvapi are already handled by felte (premature validation, a11y-problems with the bubbles on mobile etc). So, am I overlooking something important or is it just not written yet? :)
Also while at it, I had a quick look on the api and noticed that the form itself isn't passed to the validate()-function - which would make the implementation of such an validator quite a bit harder. Therefor, additional question, any reasons for that? Maybe it could be a nice addition for extensibility to pass the form as a second arg I think!
And, last but not least: Thanks again for this great, well built, library! 💯
Thank you so much for your interest! This really means a lot!
First regarding the first part of your question:
The reason I haven't focused that much on the Constraint Validation API is that it's generally not that good for a11y/mobile. In theory, even reporter-tippy is not that good if you're expecting most of your users to reach your forms with a mobile device.
But anyway, a validator's only purpose is to get the input data, validate, and return an error object back to Felte. That's why I've made the distinction between validators and reporters, since you can mix and match. E.g. validate with Yup and still show errors using the Constraint Validation API.
In that sense I have to ask, what do you mean by validator-cvapi? Do you mean giving full control to the browser (with validation attributes such as minlength or `required) to display using the CVAPI? Or do you mean a package that independently takes those attributes and validates based on them?
If it's the former, then using Felte loses a bit of its purpose since you're basically giving the browser all control back. If the latter, that's actually been on my mind but it would imply replicating what the browser does to validate each input.
Regarding the second part:
validate aims to be somewhat like a pipe that just cares about the current data in your form. In fact it works without you even needing to add use:form to your form and mutating your data store programmatically. Needing your form element implies that you actually need to modify Felte's behaviour to some extend, which is why it's only available using the extend property. This is currently a bit hacky, which is why I've opened #30, since I am hoping to make the extender API to be the solution for any complex behaviour change. If you do have any comments regarding how extensions should work, adding them to #30 would be really helpful to me!
Again, thanks a lot for giving Felte a try and I hope you enjoy using it!
I totally understand your concerns and your reasoning behind the API as it is. My idea is simple to mitigate the shortcomings of the native validation-api with felte and use the good parts (like native i18n). This should be perfectly possible because of the nice design of felte! ;)
Basically what I had in mind is the following:
Given a simple form like (simplified for demo purposes):
<form>
<input type="email" required />
<input type="password" minlength={8} required />
<button type="submit">Submit</button>
</form>
I want the following behaviour:
- add novalidate to the form
- use a custom felte-validator to get the native validity-state of the form (f.e. via checkValidity())
- render the given error-messages of the inputs (
HTMLObjectElement.validationMessage) with the given renderer (f.e. renderer-dom)
Basically I want to use the validation the browser would do normally anyways. I don't want to use the builtin "bubbles" and I don't want the form to be in an invalid state direct after mounting - for the correct a11y-concerns. Those things should be farther handled by felte.
Benefits of the approach:
- No extra weight on the bundle for simple forms
- Don't repeat yourself. Adding the same rules via zod or similar seems like unnecessary repition/overhead.
- Includes i18n for basic messages.
- Perfect progressive enhancement
- Mitigating the downsides of the native validation-api with felte
If I didn't miss anything important, it seems like a perfect match with very little overhead :)
Let's actually keep this open until the PR gets merged. I quite like the approach of letting the issue close by itself when merging a related PR. Since this issue is actually still a thing until your solution gets merged 😊