Form State and Validation Patterns

## What the default actually is A `<form>` is a navigation element. Submitting it makes the browser build a request from the form's fields and navigate to the URL in its `action` attribute using its `method`. If there is no `action`, the target is the current URL. Either way the document unloads and a fresh one is loaded, which for a single-page React app means the component tree is destroyed and rebuilt, every `useState` value is back to its initial value, and any half-finished work is gone. What the user perceives is "the page flashed and my form is empty". This is HTML behaviour, not React behaviour. It predates you and it is the default because forms worked this way before JavaScript existed. ## Preventing it ```jsx function handleSubmit(event) { event.preventDefault(); // now it's an ordinary function call if (!isValid(values)) return; submitToApi(values); } return <form onSubmit={handleSubmit}>…</form>; ``` `event.preventDefault()` cancels the browser's default action for that event. React does not do this implicitly for `onSubmit`; your handler runs and then the navigation happens unless you stop it. The event object React hands you is a SyntheticEvent, and `preventDefault` on it does what you expect on the underlying native event. Call it first, unconditionally. A handler that only prevents the default on the validation-failure path will still navigate away on the success path, which is a bug that hides behind "well, it worked when the data was wrong". ## Put the handler on the form A common alternative is `onClick` on the submit button. It mostly works, and that is what makes it dangerous. There are several ways to submit a form: clicking a submit button, pressing Enter in a single-line text field ("implicit submission", which browsers usually route through a synthetic click on the default submit button — but not when the form has no submit button), and calling `form.requestSubmit()` from code. `onSubmit` on the form is the single funnel every one of these passes through. It is also where `preventDefault` semantically belongs: you are cancelling a *submission*, not a *click*. A related trap lives in the same neighbourhood: a `<button>` inside a form with no `type` attribute defaults to `type="submit"`. So a button whose `onClick` opens a modal or adds a row will *also* submit and reload the form. Any button in a form that is not the submit button needs `type="button"` explicitly. ## After preventDefault Once the default is cancelled, the submit path is ordinary React code: - validate the whole values object, not only the fields the user touched, and bail out early if it fails; - set a pending flag so you can disable the submit button and render a spinner — otherwise an impatient user fires the request two or three times; - `await` the request and handle both outcomes: on failure, surface a form-level error and keep the values so the user does not retype them; on success, reset or navigate; - clear the pending flag in both branches, typically in a `finally`, or the button stays disabled forever after an error. ```jsx async function handleSubmit(event) { event.preventDefault(); setPending(true); try { await submitToApi(values); } catch (err) { setFormError('Could not save. Please try again.'); } finally { setPending(false); } } ``` ## Do not forget the server Cancelling the default submission means the request now leaves on your terms — your URL, your headers, your JSON body. It does not mean the data has been checked. Whatever the client validated, the server validates again. ## The React 19 alternative React 19 also lets you pass a *function* to a form's `action` prop rather than a URL. In that mode React calls your function when the form is submitted and takes care of the default navigation itself, so there is no `preventDefault` to write. It is a different submission model with its own pending and result plumbing; the `onSubmit` + `preventDefault` pattern described here is still completely valid, and it is what you will find in most existing code.