Calling form.handleSubmit() can run several phases: field validation, form validation, and onSubmit. Any of these phases may throw because of an application error. With onSubmitInvalid being added, submission failures need consistent behavior regardless of where they originate.
Normal validation failures should remain distinguishable from unexpected exceptions, and the behavior of form.handleSubmit() should not depend on which submission phase failed.
Planned for behaviour
- Call
onSubmitInvalid for exceptions from field validation, form validation, and onSubmit, in addition to reported validation issues.
- Pass a
cause to onSubmitInvalid that identifies the failing phase, such as "field_validation" | "form_validation" | "on_submit".
- Do not catch exceptions thrown by
onSubmitInvalid. This allows consumers to throw deliberately when they want the rejected promise to reach an error screen or other error boundary.
- Determine the rejection of the
form.handleSubmit() promise before invoking onSubmitInvalid, so the callback cannot change whether the original submission error rejects.
Validation results should still be inspectable separately from exceptions:
// `cause` === `"field_validator" | "form_validator"`
const { errors, cause } = await form
.handleSubmit()
.catch(() => 'real error thrown')
const isInvalid = errors.length > 0
Some thoughts
The exact cause discriminator names still need to be made consistent. The proposed behavior uses the same categories regardless of whether they are ultimately named field_validation and form_validation or field_validator and form_validator.
Calling
form.handleSubmit()can run several phases: field validation, form validation, andonSubmit. Any of these phases may throw because of an application error. WithonSubmitInvalidbeing added, submission failures need consistent behavior regardless of where they originate.Normal validation failures should remain distinguishable from unexpected exceptions, and the behavior of
form.handleSubmit()should not depend on which submission phase failed.Planned for behaviour
onSubmitInvalidfor exceptions from field validation, form validation, andonSubmit, in addition to reported validation issues.causetoonSubmitInvalidthat identifies the failing phase, such as"field_validation" | "form_validation" | "on_submit".onSubmitInvalid. This allows consumers to throw deliberately when they want the rejected promise to reach an error screen or other error boundary.form.handleSubmit()promise before invokingonSubmitInvalid, so the callback cannot change whether the original submission error rejects.Validation results should still be inspectable separately from exceptions:
Some thoughts
The exact
causediscriminator names still need to be made consistent. The proposed behavior uses the same categories regardless of whether they are ultimately namedfield_validationandform_validationorfield_validatorandform_validator.