That's nice, I'll use that next time. Although it always feels kind of bad to write client side validation code because you're going to have to do the same checks on the server side anyway.
I find it sad that so many frameworks leave the developer to duplicate server-side and client-side validation. There are obviously some things you can't reasonably validate on the client, but I'd like to see more automated ways to take backend constraints and check them on the client too.
Ideally constraints would also propagate from model definitions, so there could be a single source of truth for "what phone numbers do we accept". Some years back I tried to do this by parsing SQL table definitions, but never got far enough. Django does this, but it lacks pretty much any client-side validation support IIRC. (Or client-side anything, really...)
One of the compelling reasons to use Javascript-based frameworks like nextjs or remix.run is that you can reuse the same logic + types on the frontend and backend.
With Typescript, this is now my preferred way to build full-stack sites.
You could use something like json-schema to define constraints, and use json-schema validator libs on the front and back end to validate the form data against the schema.
You still need to handle the "what happens next" part on each side, but at least your validation rules are shared.
Why is that bad? Both have uses:
1. Client-side validation is for immediate feedback for the user.
2. Server-side validation is to block malicious actors
