Server actions with JS disabled: redirect after POST?

[chris-jarman]

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 via useFormState.

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?