Nextjs serverValidate doesn't return accurate typed-values
Hello, I followed this example to setup Nextjs backend validation https://tanstack.com/form/latest/docs/framework/react/examples/next-server-actions
I'm using zodv4 for validations.
The serverValidate has objectify-ed the array and stringify-ed the numbers as you can see in the screenshots. Have I missed something in the configuration ? Should I Object.values every array and parseFloat every number resulting of the validated data ?
By the way, love this library so far and I really enjoy using it, thank you for it, keep up the very good work!
React TanStack Form Next Server Actions Example | TanStack Form Docs
An example showing how to implement Next Server Actions in React using TanStack Form.
9 Replies
sharp-indigo•5w ago
Can't recall off of the top of my head. Since it's
FormData being passed, this kind of stringification is expected, but I'm not sure where the intended way ends and accidental bugs begin. I'll try to check later this week if that's alrightrare-sapphireOP•2w ago
Yes no problem on my side, I'll do manual conversion in the meantime and check again later, thanks 😉
Hey @Luca | LeCarbonator did you have time to take a look at this ?
The expected type returned from servervalidate should be the one validated by zod. The thing is I find it really weird that the data returned is not but I might miss something.
If serverValidate effectively does a validation using zod, shouldn't the formdata be objectify-ed before zod-parsing inside serverValidate ? If so, you should already have the data well formatted for the return of serverValidate, no ?
I'm taking a look at the function createservervalidate in your repo
rare-sapphireOP•2w ago
the return value if !onServerError should be the values returned by runValidator and not values decoded by formdata-decode, shouldn't it ?
rare-sapphireOP•2w ago
looking at standard schema validator
rare-sapphireOP•2w ago
aaah standardSchemaValidate.validateAsync() doesn't return values if successful
rare-sapphireOP•2w ago
Is it expected behavior ?
gonna try what formdata-decode does to the values because I have no clue
Ye so the decode() from the decode-formdata package returns the same formatting as servervalidate (kinda expected that 😂) if I don't pass additional params other than the formdata
sharp-indigo•2w ago
Sorry for the delay, we’ve been busy fixing some regressions + library compatability.
Once it‘s done, this can be properly addressed. Unless it‘s a runtime problem instead of a type problem?
rare-sapphireOP•2w ago
Don't worry, I guessed that you were kinda busy that's why I've been digging for the past 2 hours on it... And honestly I might just drop formData altogether because type handling is a freaking nightmare using it 😂
But I understood more about how your serverValidate expects to function and it seems not bug-related but only a type conversion nightmare cause of formdata
rare-sapphireOP•2w ago
For future references, here's what I came up with :
- onServerValidate must contains the direct schema (formOptions are useless, only onServerValidate is used in the createServerValidate)
- when dealing with anything other than a string as value in formdata, use the second param of serverValidate to pass down to the decode function in the underlying function (the result of the decode will be what is send back to you if schema parsing is successful), here's decode documentation : https://github.com/fabian-hiller/decode-formdata
