Skip to content
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

[Feature]: Unexpected errors are actively suppressed #395

Open
danclarke opened this issue Oct 9, 2024 · 2 comments
Open

[Feature]: Unexpected errors are actively suppressed #395

danclarke opened this issue Oct 9, 2024 · 2 comments

Comments

@danclarke
Copy link

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.

@airjp73
Copy link
Owner

airjp73 commented Oct 9, 2024

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)

@danclarke
Copy link
Author

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>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants