formal mountain
Remix makes forms a breeze. However, when you need to have rich client-side validation, you need to smack everything in state again and there is not much benefit anymore regarding ease of forms (compared to, say, plain React with Formik ...).
What is the best practise here? Do I miss something about the client-side validation flow? Or with Remix, is it recommended to just handle validation on the server either way?
rocky pollen
Remix makes forms a breeze. However, when you need to have rich client-side vali...
Typically it’s suggested to move validation to the server using a library like zod to validate types once it gets there. You use base HTML form validation that inputs provide and then you do harsher tests on the server before spitting back success or error
You can in theory bring zod to the browser but it’s a hefty boy and can really increase your bundle size by doing that. So the general recommendation is for zod as a server library
For base HTML input validation you have length checks, you can have patterns set and then anything else is generally a server responsibility
There are definitely still points where managing state and doing bigger checks can be beneficial but I’d say it’s pretty uncommon
formal mountain
One downside is the UX part of the native HTML input validations, right? AFAIK that does not play nice with libraries like Chakra UI 🤔
rocky pollen
One downside is the UX part of the native HTML input validations, right? AFAIK t...
It should not really impact your front end that much, It does take time to be used to their usage, and honestly sometimes I just skip it in favor of backend validation. A lot of input validation isn't super strict, in fact I don't think that it ever really stops a form submission, except for maybe required fields and length. If you want to validate on the front end right before you send it you can also generally get the e.target.form and loop through formData values there. But at that point I'd say just wait for it on the backend.
What part of validation is impacting your UX with HTML? I also haven't used Chakra UI, mainly I've used material UI when it comes to libraries and you can basically boil them down to actual input elements. I don't use the built in FormControls or anything like that with UI libraries though. I find them to be too annoying to use and makes it harder to use standard submission
formal mountain
Regarding UX with native form validation, check this example: https://dd3bqs.csb.app/
Try to enter one char in every field and press 'submit'.
rocky pollen
Is that necessarily poor UX? It tells you the issue and that is a real constraint your system has and is asking for. It's up to the developer to decide how restrictive or not they want to or need to be right?
The alternative is now there's a network request in between you and the form that's gonna say "hey you didn't give us enough characters" and if they have spotty or poor internet it can take much longer for that same feedback
If you're saying the better would be the popup that shows below the field when its "incorrect" I would say that's worse UX personally
@formal mountain
The reason i dislike the popup with a custom "red x" and error message, it's because it alters the dom and shifts the form around entirely, either injecting space between the lastName entry and Password or between Password and Submit. Also possibly stretching the length of the form inputs
formal mountain
But when you get your response from the server, it will shift the UI as well, right?
You still have to smack it on the screen somehow
rocky pollen
It doesn't have to if you use a toaster as an error message or a window alert, most small specific errors should be caught by the initial form element telling you what's wrong and then you can have a concise error message saying what the user did wrong on the form. You can certainly add error messages that alter the dom and how things are shaped, but I'd say that's inherently poor UX because the whole document is changed because of an error and there are ways to make that not happen. Either absolute positioning on an element with a text box to create a similar style tooltip.
I'm not gonna pretend I never have my content shift from a form failing, but I do try to avoid it unless the UI is too specific and painful for that to be a feasible solution. Most time's I feel I'm able to say what the issue is in just a toaster
formal mountain
Makes absolutely sense what you're saying 🙂
It's kinda the 'trend' or whatever, but it doesn't mean that's the best option
rocky pollen
It's kinda the 'trend' or whatever, but it doesn't mean that's the best option
I’ll say it is semi trendy, but the trend is often about accessibility. A lot of libraries royally mess up accessibility and are actually worse than just using plain html even if they’re aiming to be inclusive. It depends how much you want to support screen readers and keyboard navigation, those sorts of things. A content shift doesn’t destroy keyboard movement but unless your message is properly marked for aria screen readers may flat out ignore it and your user can not know what went wrong.
https://darekkay.com/blog/accessible-ui-frameworks/ This is older but somewhat illustrates the point. It’s possible in more recent times these libraries have gotten better, but there’s a lot that goes into accessibility that’s very easy to mess up.
tropic bane
Remix makes forms a breeze. However, when you need to have rich client-side vali...
You dont need to put everything in state. The web already has an advanced api for validation.
You only need
