You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the new or updated feature that you are suggesting?
When a validation error occurs for an unexpected field, it should be easily accessible. Currently, if an error occurs the 'onInvalidSubmit' handler is called, but it has no arguments or information on what was invalid. If you call form.error you have to know ahead of time all the possible error keys. If the error is in an unexpected key, you won't know and the form will appear to be broken. Instead, I think there should be an 'errors' object or array where all errors can be found and enumerated.
In my specific case, I had a strict Zod schema that doesn't allow keys beyond the ones expected. This returns an error on a blank key, with the error specifying the problematic additional key. The error was the additional RVF form ID: Unrecognized key(s) in object: 'rvfFormId'. With a normal form this results in the submit button appearing to do nothing. There are no errors for the form fields, yet the form will not submit. In other dynamic scenarios additional keys could appear that aren't expected, but would also trigger the validation to fail with no error messages.
Why should this feature be included?
Without the possibility to show additional unexpected errors, forms can appear completely broken. Even as a developer, I spent an inordinate amount of time tracking down why the form wouldn't submit. Unexpected errors happen from time to time, and we should always do our best to present something useful to the user. Worst case we should have a useful log of the error somewhere and a generic error to the user.
The text was updated successfully, but these errors were encountered:
I've definitely run into this before, too. Now that we track refs for everything in v5, we could probably use those to determine if an error is associated with a field and add an API to access errors that don't have fields. This still only works if you know to look for that, though. I wonder if there's a reasonable way to proactively surface these?
Instead, I think there should be an 'errors' object
This exists already via form.formState.fieldErrors or form.transient.formState.fieldErrors (docs)
Ah that's handy, didn't see that! I can use zod-key-parser to get all the expected keys, and then get the 'outliers' to present to the user.
Surfacing via the API might be possible with an additional 'unknownErrors' or 'unexpectedErrors' field? You can use form.error('field') for the fields, and at the top of the form something like <ul>{ form.unknownErrors.map(x => <li>{x.key}: {x.value}</li)> }</ul>
What is the new or updated feature that you are suggesting?
When a validation error occurs for an unexpected field, it should be easily accessible. Currently, if an error occurs the 'onInvalidSubmit' handler is called, but it has no arguments or information on what was invalid. If you call form.error you have to know ahead of time all the possible error keys. If the error is in an unexpected key, you won't know and the form will appear to be broken. Instead, I think there should be an 'errors' object or array where all errors can be found and enumerated.
In my specific case, I had a strict Zod schema that doesn't allow keys beyond the ones expected. This returns an error on a blank key, with the error specifying the problematic additional key. The error was the additional RVF form ID:
Unrecognized key(s) in object: 'rvfFormId'
. With a normal form this results in the submit button appearing to do nothing. There are no errors for the form fields, yet the form will not submit. In other dynamic scenarios additional keys could appear that aren't expected, but would also trigger the validation to fail with no error messages.Why should this feature be included?
Without the possibility to show additional unexpected errors, forms can appear completely broken. Even as a developer, I spent an inordinate amount of time tracking down why the form wouldn't submit. Unexpected errors happen from time to time, and we should always do our best to present something useful to the user. Worst case we should have a useful log of the error somewhere and a generic error to the user.
The text was updated successfully, but these errors were encountered: