Chapter 17: resetDefaultValues

Core Idea

resetDefaultValues(values, options?) (7.77.0+) advances the form's internal baseline for dirty-tracking without touching what the user currently has typed — useful for "advance the baseline to the just-saved values so only further edits count as dirty" after an async submission.

Key Concepts

• Never modifies current form values: only the baseline used to compute dirtyFields/isDirty.
• keepDirty: preserve existing dirtyFields as-is instead of recomputing against the new baseline.
• keepIsValid: skip re-running validation; isValid stays as it was.
• Common use case: a submit button disabled while !isDirty — after a successful async save, call resetDefaultValues(savedData) so the button re-disables until the next real edit, instead of staying enabled because the form still looks "dirty" against the pre-submit baseline.

Code Examples

const onSubmit = async (data) => {
  await saveToServer(data)
  resetDefaultValues(data) // baseline advances; isDirty only true for edits after this point
}

<button type="submit" disabled={!isDirty}>Save</button>

• What it demonstrates: the exact "disable save until dirty again" pattern this method exists for.

Anti-patterns

• Using reset(data) instead when you only want to move the baseline: reset also touches current form values/subscriptions; resetDefaultValues is the narrower, values-preserving tool.

Key Takeaways

1. resetDefaultValues changes what "dirty" is measured against, not what's currently in the form.
2. Pair it with a post-submit save flow to correctly re-disable a "Save" button gated on isDirty.

Connects To

• useform-reset: the broader operation that also touches current values.
• useform-resetfield: the single-field equivalent of resetting (values, not baseline).
• useform-formstate: where isDirty/dirtyFields live.