-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(qwikcity/actions): dotnotation field-errors #6568
Conversation
On very complex nested types, you loose the location or the field the error belongs to. Closes QwikDev#5463 BREAKING CHANGE: The fieldErrors type on the action changed from Record<string,string[]> (simplified) to Record<string,string> where the key is now dot notation closes QwikDev#5463
👷 Deploy request for qwik-insights pending review.Visit the deploys page to approve it
|
@gioboa this is my idea of fixing #5463 Let me know what you think. Added the infos to the docs. We are now in production without passing validation and using this flattenZodMap locally in the action body. Did a draft, as I had issues linking this. Some dirty task for spa_init. Not sure if I am the cause. |
commit: @builder.io/qwik
@builder.io/qwik-city
eslint-plugin-qwik
create-qwik
|
…design/qwik into feat/dotnotation-field-errors
@gioboa I added the array field. I was reading the code and thought about arrays in general. My change is helping a lot with deep nested objects, but it's the same kind of unhelpful with complex forms having arrays with objects and arrays. I guess we could make it even more complex, but I don't think it's necessary for 99% of the people out there. |
Thanks @tzdesign 🚀 for this great piece of code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested the solution and it's working fine.
You added docs and test, what a great job. Thanks @tzdesign
Overview
On very complex nested types, you loose the location or the field the error belongs to.
BREAKING CHANGE:
The fieldErrors type on the action changed from
Record<string,string[]>
(simplified) to
Record<string,string | string[]>
where the key is now dot notationCloses #5463
More context
@ulic75 added the possibility for complex form with the PR #4634 and we were trying to use it in our cart. As you might imagine, the cart type is very complex and has more than one level. Example action with comparable type here:
As you can see. You can't determine if address.street is failing exactly, as the errors on address are just an array of strings.
With my approach the errors are the following type:
With this in mind, the name of the input and the field in
fieldErrors
will be exactly the same.And what's impossible now, becomes possible:
Arrays
Since @ulic75 also made something like
person.0.name
possible, I had to change the type for fieldErrors tostring | string[]
. This means if you have arrays in your validation there are two things which can happen.The array is missing in the provided data:
fieldErrors
will have the propertyarrayName[]
with an array as type.Example output:
The array is NOT missing, but data does not validate:
For example you have addresses like
{street: string, zip: number}[]
as validation type. You pass address street, but forgot about zip. You will get this:What is it?
Checklist: