Server actions with JS disabled: redirect after POST? #64787
Unanswered
chris-jarman
asked this question in
App Router
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Apologies if I've missed something fundamental, but I'm confused by server actions.
When JavaScript is enabled, Next invokes server actions by making an implicit AJAX POST request containing the relevant form data, and the response is returned as an RSC payload. The client-side JS picks this up, and updates the UI accordingly. So far, so good.
However, one of the key selling points of server actions is the ability to transparently support "JavaScript disabled" scenarios, by gracefully degrading to a full-page form POST request... which in turn triggers a full server-side render of the page. If, for example, I have a server action that performs some mutation (like deleting a resource), a browser refresh will re-send the POST.
It has long been established good practice to redirect to a GET request after handling a POST, to avoid accidental resubmission. How exactly are we supposed to do this in Next?
I am able to call
redirect
within my server action to mitigate the issue, but with JavaScript enabled this causes a full refetch of the page, and also nerfs the ability to handle the response viauseFormState
.I don't see a way to determine, from within the server action, whether the action was invoked via an AJAX request vs. a "full page browser POST", if that makes sense. I would like to conditionally redirect to a GET only when JavaScript is disabled. Is there a canonical way we should be using server actions to support both JS and no-JS flows?
Beta Was this translation helpful? Give feedback.
All reactions