Fixes #1681

Thanks for the detailed repro. It made this much easier to pin down.

Problem

If you call form.reset(newValues) inside onSubmit and your framework re-renders the component immediately after, the reset values get silently overwritten.

reset(newValues) writes the new values into this.options.defaultValues. When the adapter calls update() on re-render with the same props it had before, update() compares the incoming defaultValues against oldOptions.defaultValues (which now holds the reset values rather than the original component defaults), sees a delta that isn't really a change, sets shouldUpdateValues = true, and reverts the form back to the original defaults.

There's a second issue: this.options = options runs on every re-render, replacing the whole options object. After a reset(), the runtime defaultValues is gone. A later no-arg reset() uses the stale component default instead of the post-submit baseline.

Fix

The root problem is that update() has no way to tell "the component's defaultValues prop actually changed" apart from "someone called reset() and now defaultValues looks different." This adds a private _componentDefaultValues field that tracks what the adapter last explicitly provided, separate from the runtime this.options.defaultValues that reset() writes to.

In update():

• componentDefaultsUnchanged = evaluate(options.defaultValues, prevComponentDefaultValues) is computed before the field is overwritten.
• shouldUpdateValues now requires !componentDefaultsUnchanged, so an unchanged re-render can't clobber a reset.
• When component defaults are unchanged and a prior baseline exists, this.options gets a fresh spread object with the runtime defaultValues preserved. The spread avoids mutating the caller-supplied reference, which matters when the adapter passes a memoized frozen object.

The constructor guard (oldOptions.defaultValues !== undefined) keeps the restoration block from firing on the very first update() call, where oldOptions is the empty class default {}. Initial form values come from baseStoreVal before that first call, so the guard is safe.

Tests

Two regression tests in FormApi.spec.ts:

1. update() with unchanged props after reset(newValues) keeps values at the reset value, not the original default.
2. A follow-up no-arg reset() uses the post-submit baseline, not the original component default.

Summary by CodeRabbit

• Bug Fixes
  • Fixed a race condition where calling reset(newValues) during submission could be overwritten by a later update() triggered by component re-renders when defaultValues props were unchanged.
  • Improved reset() consistency after updates: calling reset() without arguments now uses the reset baseline instead of reusing unchanged component-provided defaults.