[1.x] useForm wrongly overwrites default values ​​after successful submission

[WillRy]

reset from useForm is not functional after a successful submission. This is due to the form's internal onSuccess hook setting defaults to the current form state (line 172).

The bug happens in any version above 1.0.14 in vue3

Look at line (172).

inertia/packages/vue3/src/useForm.ts

Lines 163 to 175 in 0fc4b1c

	onSuccess: async (page) => {
	this.processing = false
	this.progress = null
	this.clearErrors()
	this.wasSuccessful = true
	this.recentlySuccessful = true
	recentlySuccessfulTimeoutId = setTimeout(() => (this.recentlySuccessful = false), 2000)
	const onSuccess = options.onSuccess ? await options.onSuccess(page) : null
	defaults = cloneDeep(this.data())
	this.isDirty = false
	return onSuccess
	},

Whem we look at the source code of React and Svelte drivers, we dont see this behaviour. Older versions of the Vue codebase also do not have this line of code.

Steps to reproduce:

1 - Setup a form

import { useForm } from '@inertiajs/vue3'

const form = useForm({ email: '' })

2 - Change form data

form.email = '[email protected]'

3 - Submit form

form.post("/endpoint", {
  onSuccess: () => {
    //after some secconds, make reset
    setTimeout(() => {
      form.reset();
    }, 1000);
  },
});

After this we can see the bug, form.reset will not work, as the values ​​previously sent in the form will become the new default values, breaking the functioning of form.reset

Workaround

As a workaround, it is currently necessary to do a trick

function resetForm() {
    form.defaults({email: ""})
    form.reset()
}

Solution

As a solution, the line that causes this unwanted behavior of resetting default values ​​improperly has been removed.

[pedroborges]

Thanks @WillRy! I can confirm that the React and Svelte adapters don't reset the default values after successful submission ✅

[joetannenbaum]

Looks good, thank you!

[reinink]

Hey just a heads up that we decided to revert this change.

I understand the reasoning for the change, but unfortunately whether you want this behavior or the current behavior kind of depends on whether your form is updating something, or if your form is creating something. If you're creating something, then this change makes sense, but if you're updating something the current behavior makes sense. Meaning if we make this change it fixes one situation but breaks another.

Given that, and given that this is technically a breaking change, we've decided to leave this out now and revisit it for v2.0.

I think either way in v2.0 we should get all the adapters working the same way — one way or the other.