Form Resubmissions
On this page

Form Resubmissions

When you use <Form method="post"> in Remix, as opposed to using the native HTML <form method="post">, Remix does not adhere to the default browser behavior for resubmitting forms during navigation events like clicking back, forward, or refreshing.

The Browser's Default Behavior

In a standard browser environment, form submissions are navigation events. This means that when a user clicks the back button, the browser will typically resubmit the form. For example:

  1. User visits /buy
  2. Submits a form to /checkout
  3. Navigates to /order/123

The browser history stack would look like this:

GET /buy > POST /checkout > *GET /order/123

If the user clicks the back button, the history becomes:

GET /buy - *POST /checkout < GET /order/123

In this situation, the browser resubmits the form data, which could lead to issues such as charging a credit card twice.

Redirecting from actions

A common practice to avoid this issue is to issue a redirect after the POST request. This removes the POST action from the browser's history. The history stack would then look like this:

GET /buy > POST /checkout, Redirect > GET /order/123

With this approach, clicking the back button would not resubmit the form:

GET /buy - *GET /order/123

Specific Scenarios to Consider

While accidental resubmissions generally don't happen in Remix, there are specific scenarios where they might.

  • You used <form> instead of <Form>
  • You used <Form reloadDocument>
  • You are not rendering <Scripts/>
  • JavaScript is disabled by the user
  • JavaScript had not loaded when the form was submitted

It's advisable to implement a redirect from the action to avoid unintended resubmissions.

Additional Resources



Docs and examples licensed under MIT