Conform breaks Remix <Form /> submission with clientAction

[QzCurious]

Describe the bug and the expected behavior

Submitting a conform driven <Form /> by "press Enter on input" should not make a real POST submission to server. It should behave the same as clicking a submit button.

Quick comparison:

	Submit by click submit button	Submit by press Enter
<Form />	Acts the same as others bandicam.2024-02-23.17-38-15-684.mp4	Acts the same as others bandicam.2024-02-23.17-39-02-273.mp4
<Form /> with conform	Acts the same as others bandicam.2024-02-23.17-50-41-381.mp4	Bug: It acts the same as others AND make a real POST submission to server bandicam.2024-02-23.17-51-57-065.mp4

I've tried hard to make a very minimum reproduction to reveal root cause. I believe the bug is occurring with all of these conditions are met:

• clientAction reply with { resetForm: true }

  export const clientAction = async ({ request }: ClientActionFunctionArgs) => {
    const formData = await request.formData();
    const submission = parseWithZod(formData, { schema });
    return submission.reply({ resetForm: true });
  };

• useForm with lastResult (of cause) AND shouldValidate being "onBlur"

  const [form, fields] = useForm({
    shouldValidate: "onBlur",
    lastResult,
  });

Apply one of the following changes workaround the bug:

• Submitting the <Form /> by submit button works fine
• submission.reply(), that is, without { resetForm: true }
• Use action instead of clientAction (But I want a SPA app)
• shouldValidate being onInput or onSubmit

Conform version

v1.0.2

Steps to Reproduce the Bug or Issue

1. git clone https://github.com/QzCurious/conform-remix-vite-form-submission-bug
2. It's a Remix Vite App
3. pnpm i
4. pnpm dev and open the web page
5. Focus on "remix <Form /> with conform" and press Enter
6. Bug happens: <Form /> is handled by clientAction, AND it make a real POST submission to server.

What browsers are you seeing the problem on?

No response

Screenshots or Videos

Screen.Recording.2024-02-22.at.12.16.31.AM.mov

Additional context

Remix with Vite were just marked stable today.

[edmundhung]

This is because Conform handle everything including validation as a form submission to achieve single data flow. You should either check the submission status on the client action and just return the result back similar to action, or if you wanna minimize it hitting the client action, just set the onValidate option.

[edmundhung]

In case it wasn't clear. It hit the action twice because you triggered the field validation when you leave the field and then you triggered another validation when you click on the submit button. Since you don't have any validation defined in useForm, Conform naturally reach to client action for the validation result.

[QzCurious]

I feel like there might be some misunderstanding between us.

What I want:

Submitting a conform driven <Form /> by "press Enter on input" and it should acts exactly the same as others _{(I updated the post with a comparison table)}.

Response to your reply

You should either check the submission status on the client action and just return the result back similar to action

• To reduce noise in my code, I make schema always be passed. So now no status check is needed and no need to return the result.
• I wrote exact the same code with clientAction and action.

or if you wanna minimize it hitting the client action, just set the onValidate option.

No, it's not my purpose.

In case it wasn't clear. It hit the action twice because you triggered the field validation when you leave the field and then you triggered another validation when you click on the submit button.

I have no problem with this. I know how and why It hit the action twice.

Since you don't have any validation defined in useForm, Conform naturally reach to client action for the validation result.

But it not only reach to clientAction but also making a real form submission to server.

[QzCurious]

I updated the sample code to reduce noise.

This makes validation always be passed.

const schema = z.object({
-   nickname: z.string(),
+   nickname: z.string().optional(),
});

[edmundhung]

Sorry that I have misread your report and thanks for providing a very detailed description here!

Interestingly, I can reproduce your issue on Chrome but not on Firefox. I tend to think this would be an issue on the Remix side but I will try to dig deeper over the weekend and see if I can further narrow down the scope here.

There are two things suspicious here:

1. Conform will call formElement.reset() on a layout effect when the clientAction returns the new result with reset being true.
2. We might have lost the focus from the input for some reason which triggers the field validation and Remix is not able to capture it and so it becomes a native form submission (?)

[QzCurious]

TL;DR

I can't find the root cause. But I make a PR #510 that refactor conform-react to use react event. It would BYPASS the bug and make conform-react more react-ish.

---

2. We might have lost the focus from the input for some reason which triggers the field validation and Remix is not able to capture it and so it becomes a native form submission (?)

Confirmed that focus is lost from the input and conform is submitting the form for validation.

---

I'm currently can't find how Remix intercept the submission. I believe it is the lines doing intercepting:

https://github.com/remix-run/react-router/blob/428ab741024a96768db0fa0c97b17567f4a20d62/packages/react-router-dom/index.tsx#L1292

https://github.com/remix-run/react-router/blob/428ab741024a96768db0fa0c97b17567f4a20d62/packages/react-router-dom/index.tsx#L1266

I've confirm a submission would trigger submitHandler. But the attached event is not submitHandler directly. The attached function seems to do with react batching, transition things (they call it react-fiber?).

It reminds me react has its own "event handling logic". And "maybe" we should not use native event handling which "maybe" conflict to how react handle event.

With these clues, I'd rather suspect the issue is conform with react, not with Remix. And because we conflict to react logic, the bug just "constantly" and "accidentally" happened only on certain situations. But I'm sorry, I really can't prove it.

[QzCurious]

Hi @edmundhung, no rush. Have you had a chance to sort any? Or how do you think about PR #510 I mentioned previously?

[edmundhung]

Sorry for the late reply. I am busy relocating to a new country right now and so haven't had a chance to debug it further yet. I saw your PR but it would be hard to ship it as is because it would be a breaking change. It will also impact on where the event listeners is binded (It was added on the document). If you are in need for a temporary solution, maybe you can consider using patch-package with your suggested change for now. I will get back to this as soon as I can.

[edmundhung]

I have also converted this back to an issue (#516) so I can keep track of it :)