server/client form validation
Unanswered
Schweizer Laufhund posted this in #help-forum
Schweizer LaufhundOP
Currently I use react-hook-form and zod to validate my forms on the client-side, which works fine, I then post the form, to an API endpoint, which in turn, re-validates the data (in case the UI was bypassed) and then updates the data somewhere. So all in all, a very common process, it has:
* Client-side form validation, so no wasted Network requests.
* State visualisation, so user knows the form has been submitted.
* Error visualisation, so user knows if the form submission failed and why.
I've been looking at the https://nextjs.org/learn tutorial to see if there is anything new so I can update my skills and they are using server actions, which I've used before, but not in anger. This tutorial only has server-side form handling, so while the form is a client-component, it uses server actions when a form is submitted. This all makes sense and they use zod for the server-side validation which is great. However, this does incur a round trip POST request to the server, I personally see as unnecessary. Yes, if JavaScript is turned off, the form still works since it is all server-side, but is that really a big issue these days? Most of my work is in online mapping and without JavaScript, there is no point using my apps anyway.
My own belief is that you should have both server and client side validation, so my question is how to do so properly?. I've come across a few blogs on the topic:
* https://nextjs.org/learn - server-side only
* https://nehalist.io/react-hook-form-with-nextjs-server-actions/ - server and client validation
* https://brockherion.dev/blog/posts/using-react-hook-form-with-nextjs-13-server-actions/ - client-side only
Even though they are all a bit different, that's fine, it is probably too early for server actions to have a consistent solution, but I am curious to know what others think on this topic, after all, most apps have some form handling .
So if there are other blogs that go into this, are considered better etc, please let me know.
* Client-side form validation, so no wasted Network requests.
* State visualisation, so user knows the form has been submitted.
* Error visualisation, so user knows if the form submission failed and why.
I've been looking at the https://nextjs.org/learn tutorial to see if there is anything new so I can update my skills and they are using server actions, which I've used before, but not in anger. This tutorial only has server-side form handling, so while the form is a client-component, it uses server actions when a form is submitted. This all makes sense and they use zod for the server-side validation which is great. However, this does incur a round trip POST request to the server, I personally see as unnecessary. Yes, if JavaScript is turned off, the form still works since it is all server-side, but is that really a big issue these days? Most of my work is in online mapping and without JavaScript, there is no point using my apps anyway.
My own belief is that you should have both server and client side validation, so my question is how to do so properly?. I've come across a few blogs on the topic:
* https://nextjs.org/learn - server-side only
* https://nehalist.io/react-hook-form-with-nextjs-server-actions/ - server and client validation
* https://brockherion.dev/blog/posts/using-react-hook-form-with-nextjs-13-server-actions/ - client-side only
Even though they are all a bit different, that's fine, it is probably too early for server actions to have a consistent solution, but I am curious to know what others think on this topic, after all, most apps have some form handling .
So if there are other blogs that go into this, are considered better etc, please let me know.
7 Replies
imo, server validation is a must. And for client side, if the form is not very complex , I would just use html validation instead
html has improve alot
Schweizer LaufhundOP
First off, thanks for the response, I agree completely on server-side, anyone that has written an API would hopefully agree on that.
As you say, only the simplest of forms should you rely on html validation but even then, I don't like that as each browser manages this differently and there is no consistency in their UIs, this is the reason why I never really use html validation. However, adding more client-side libraries does come with costs, I won't deny that.
I guess if I were to refine my question, it would be more about approach, for instance, using hooks like
I'm curious as to others experiences and pitfalls that I may not have considered/experienced.
As you say, only the simplest of forms should you rely on html validation but even then, I don't like that as each browser manages this differently and there is no consistency in their UIs, this is the reason why I never really use html validation. However, adding more client-side libraries does come with costs, I won't deny that.
I guess if I were to refine my question, it would be more about approach, for instance, using hooks like
useFormState and useFormStatus, are so new, they aren't even documented much yet, they are canary hooks, so are subject to change. This is cool to play with, but really shouldn't be used in production code, so if not, what else is there? Just stay with the status quo and use API routes and client-side fetch requests? Maybe. This is the primary area I'd like to discuss and explore.I'm curious as to others experiences and pitfalls that I may not have considered/experienced.
Schweizer LaufhundOP
I assume the
useState you'd use to record server-side errors? That is an approach I've taken previously. There isn't a use I can see to use them for client-side, if using react-hook-form, but if I'm mistaken, please elaborate.I tend to agree, while I like the idea of
useFormState and useFormStatus, since they are canary solutions, I'd rather hold off on using them right now.yes useState + server action without client side validation