jaredpalmer / jaredpalmer/formik
Expose Validation Errors to Make Troubleshooting Failed Form Submissions Easier
- Dominant language
- TypeScript
- Stars
- 34.3k
- Forks
- 2.8k
- PR merge metrics
- No merged PRs in 30d
Description
## Feature request
### Current Behavior
Currently if the `validationSchema` fails it's "silent" if there's no associated field/handler to display the error.
### Desired Behavior
It would be nice if there could be a console error or warning that brought the field to attention.
There should be an easy way for developers to debug why their form is not submitting.
### Scenario
I had an old deprecated field in my validation schema that no longer existed in the form, so the form would not submit. There was no associated error field any more either, so there was no UI to surface why the form wasn't submitting.
When I find myself in a "phantom/silent failed form submission" I often have to wrap the form in a render function to expose the errors object -- I then often wrap the `errors` like so: `
{JSON.stringify(errors, null, 2)}`. This seems like an anti-pattern for me to determine why the form is not submitting, and can be rather involved if the form is not yet wrapped in a render function.
### Suggested Solution
I would like to see an error or warning in the console that exposes the error, rather than being silent.
Ultimately it would be nice if there was a dev vs production flag to control if it displays in the console. Maybe a quick attribute that could be thrown on the `Formik` or `Form` component to help debug rather than having to expose the `errors` object.
### Who does this impact? Who is this for?
This is targeted for DX - Developer eXperience.
### Describe alternatives you've considered
I've listed the current cumbersome workaround above: wrap the form in a render function to expose `errors` then display them on the page.
### Additional context
Nope.jpg
Contributor guide
Research direction
Start by tracing how validationSchema failures populate the errors object and how Formik or Form currently exposes those errors; the issue names no files or tests. Review the existing submission and error-handling flow, then define the diagnostics behavior, including development versus production control, before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- developer-experience, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100