-
Benachrichtigungen
You must be signed in to change notification settings - Fork 46.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[React 19] allow opting out of automatic form reset when Form Actions are used #29034
Kommentare
I think you should return current values from action in such case and update the default value 😃 |
@adobe export issue to Jira project PWA |
I think you should return current values from action in such case and update the default value. and return required! |
This is very necessary in the step-by-step form, such as verifying the email in the auth form first |
Be careful to handle if the action throws an error, your "returning the new default" at the end of the function will be ineffective. |
The automatic form reset in React 19 actually caught me off guard, where in my case, I was trying to validate the form inputs on the server, then return & display the input errors on the client, but React will reset all my uncontrolled inputs. For context, I wrote a library just for doing server-side validation https://github.com/chungweileong94/server-act?tab=readme-ov-file#useformstate-support. I know that you can pass the original input ( It's easy to reset a form, but hard to restore a form. |
Now that I have played with React 19 form reset for a while, I think this behavior kind of forces us to write a more progressive enhancement code. This means that if you manually return the form data from the server and restore the form values, the user input will persist even without JavaScript enabled. Mixed feelings, pros and cons. |
what about using onSubmit as well the action to prevent default? |
If you want to opt-out of automatic form reset, you should continue using +function handleSubmit(event) {
+ event.preventDefault();
+ const formData = new FormData(event.target);
+ startTransition(() => action(formData));
+}
...
-<form action={action}>
+<form onSubmit={handleSubmit}> -- That way you still opt-into transitions but keep the old non-resetting behavior. And if you're a component library with your own action-based API that wants to maintain form-resetting behavior, you can use // use isPending instead of `useFormStatus().pending`
const [isPending, startTransition] from useTransition();
function onSubmit(event) {
// Disable default form submission behavior
event.preventDefault();
const form = event.target;
startTransition(async () => {
// Request the form to reset once the action
// has completed
ReactDOM.requestFormReset(form);
// Call the user-provided action prop
await action(new FormData(form));
})
} --https://codesandbox.io/p/sandbox/react-opt-out-of-automatic-form-resetting-45rywk We haven't documented that yet in https://react.dev/reference/react-dom/components/form. It would help us a lot if somebody would file a PR with form-resetting docs. |
@eps1lon do you think using I am surprised by this new default behavior here, because this forces essentially everyone to use So if this reset behavior is a 100% set in stone for React 19, why not suggest using |
@rwieruch I'm not sure this is true. As @acdlite mentions in the PR below, it's for uncontrolled inputs.
Controlled inputs are probably in almost every form case still desirable with RSC (as Sebastian mentions "I will also say that it's not expected that uncontrolled form fields is the way to do forms in React. Even the no-JS mode is not that great.") Also, this is about "not diverging from browser behavior", as @rickhanlonii mentions in more discussion over on X here: But it does indeed seem to be a controversial choice to match browser behavior and reset uncontrolled fields. |
Thanks for the input here @karlhorky and putting all the pieces together. I have seen that this matches the native browser more closely, so I see the incentive for this change. Just wanted to double check here, because I am re-adjusting my teaching material again (my own fault here, because we are still quite early on this :)). So if I am not using a third-party library for forms or actions, would the following code look good for upserting an entity with form + server action, if I still would want to use the const TicketUpsertForm = ({ ticket }: TicketUpsertFormProps) => {
const [actionState, action] = useActionState(
upsertTicket.bind(null, ticket?.id),
{ message: "" }
);
return (
<form action={action} className="flex flex-col gap-y-2">
<Label htmlFor="title">Title</Label>
<Input
id="title"
name="title"
type="text"
defaultValue={
(actionState.payload?.get("title") as string) || ticket?.title
}
/>
<Label htmlFor="content">Content</Label>
<Textarea
id="content"
name="content"
defaultValue={
(actionState.payload?.get("content") as string) || ticket?.content
}
/>
<SubmitButton label={ticket ? "Edit" : "Create"} />
{actionState.message}
</form>
);
}; And then the action returns the const upsertTicketSchema = z.object({
title: z.string().min(1).max(191),
content: z.string().min(1).max(1024),
});
export const upsertTicket = async (
id: string | undefined,
_actionState: {
message: string;
payload?: FormData;
},
formData: FormData
) => {
try {
const data = upsertTicketSchema.parse({
title: formData.get("title"),
content: formData.get("content"),
});
await prisma.ticket.upsert({
where: {
id: id || "",
},
update: data,
create: data,
});
} catch (error) {
return {
message: "Something went wrong",
payload: formData,
};
}
revalidatePath(ticketsPath());
if (id) {
redirect(ticketPath(id));
}
return { message: "Ticket created" };
}; EDIT: I think that's something @KATT wanted to point out in his proposal: #28491 (comment) |
Yup, that’s pretty much it. This way it works the same if submitted before hydration happens |
Resetting the form automatically is a real head-scratcher. How should we preserve the state of a form when errors occur? Using Using controlled components defeats the purpose of The example here is deceptively simple, as there are no visible form inputs. What am I missing? |
The docs are misleading on this topic because on the React 19 docs, it's the React 18 canary version that is shown as an example which does not reset the form. https://19.react.dev/reference/react-dom/components/form#handling-multiple-submission-types |
Automatic form reset only applies when passing functions to the The original issue description isn't explicit about this. @LutherTS If there was a change in behavior to APIs available in previous React stable versions, please include a reproduction. |
@eps1lon You're correct, the feature has only been available since the React 18 canary version so it's only going to be breaking for those using the canary version. However, the canary version is the default version running on Next.js, so the change may be breaking for a significant number of codebases there. |
The same thing doesn't apply to NextJS app router tho, where both |
Sure, but that would be an issue for Next.js. I don't think we rolled this change out in a 14.x Next.js stable release. The automatic form reset was enabled in #28804 which was included in vercel/next.js#65058 which is not part of any stable Next.js release as far as I can tell. |
OK, so what you're saying is this behavior only happens in Next.js 15 RC which uses React 19 RC, both of which being currently unstable, and therefore this is a trade-off for using unstable versions. Then at the very least the React 19 docs should reflect these changes. And I reiterate that if these changes are reflected in the React 19 docs, the entire example for "Handling multiple submission types" is completely irrelevant, because there is no point in saving a draft if after saving said draft it disappears from the textarea. So how does the React team reconcile presenting a feature for one purpose when the actual feature currently does the exact opposite? |
True, fair enough.
Yes, it is not. But that's the whole points right, where we feedback on a feature before stable release. I do think that auto form reset behaviour does bring some benefits in terms of progressive enhancement, but if you think again, React is kinda doing extra stuff unnecessarily. By default, the browser will reset the form when we submit it, then when we submit a form via JS(React), it retains the form values after submit, but React then artificially reset the form. Yes, form reset is a cheap operation, but why not make it an option for people to opt-in instead of doing it automatically. |
And that's certainly appreciated. Though there's an important difference between a change in behavior and the behavior of a new feature. The comments here read as though this breakage is not the norm when we didn't change any behavior between stable, SemVer minor React releases nor between stable, SemVer minor Next.js releases. Changes in behavior between Canary releases should be expected. Now that we established that this isn't a change in behavior, we can discuss the automatic form reset. The reason this was added was that it matches the native browser behavior before hydration or with no JS (e.g. when |
I have no minimal example at hand, but it seems like |
That seems like something you should be able to highlight starting with https://react.new. Though I believe |
This is actually intended. |
It would be really great to make this opt-in instead of opt-out! I understand react is trying to mirror the default behavior of the browser here, but, as the people commenting on this issue seem to suggest, that isn't the expected behavior. My use case (and the use case that is highlighted on the nextjs docs) is server-side validation. If you receive an error back from the server, I can't think of any case where it would make sense to reset all of the form fields. I spent 10 minutes thinking that this was a re-rending issue that I had created because the expected behavior didn't line up with reality. Another example- and the one highlighted on the react docs -is saving a draft. Pretty annoying to click "save draft" and have your draft disappear. I understand that making resetting not the default could be hard as it's seemingly marked stable in nextjs, but at least something like a |
* feat: optimistic comments * fix: all good fixed automatic reset behaviour facebook/react#29034 * fix: add error boundries and better UI
Summary
repo: https://github.com/stefanprobst/issue-react-19-form-reset
react 19@beta currently will automatically reset a form with uncontrolled components after submission. it would be really cool if there was a way to opt out of this behavior, without having to fall back to using controlled components - especially since component libraries (e.g.
react-aria
) have invested quite a bit of time to work well as uncontrolled form elements.the main usecase i am thinking of are forms which allow saving progress, or saving a draft, before final submit. currently, every "save progress" would reset the form.
The text was updated successfully, but these errors were encountered: