Uncaught Error: The submit event is dispatched by form#a instead of form#b

[marilari88]

Describe the bug and the expected behavior

When attempting to submit a form within a radix-ui dialog, I encountered an error message in the console: "Uncaught Error: The submit event is dispatched by form#b instead of form#a". The form#a resides within the dialog.

To illustrate this issue, I've provided a reproducible example here: link.

It appears that despite only submitting form#a, the submit event handler of form#b is triggered.

Conform version

v1.1.0

Steps to Reproduce the Bug or Issue

1. Open https://stackblitz.com/~/github.com/marilari88/conform-with-dialog or clone locally if you prefere this
2. Press 'add player'
3. Fill the name and goal field
4. Submit

What browsers are you seeing the problem on?

Chrome

Screenshots or Videos

Additional context

No response

[edmundhung]

Interesting! This might be a bug on React? It can be resolved by moving the dialog out of the team form. Although the dialog will renders the player form outside of the team form, but the react submit event still bubbles up through the virtual dom, which triggers the onSubmit handler on the team form and trigger the error you had.

[houmark]

Nested forms is not allowed in HTML, so that appears to be the base reason for the error.

I read in the docs that you should be able to use a FormProvider/FormContext in Conform to control which form you submit, but I have not tested this myself and wonder why @edmundhung did not suggest that as a solution, so maybe I am misunderstanding something here. If that's the case, then please disregard, but just wanted to mention a possible solution if you are not able to move your dialog outside the parent form.

[edmundhung]

The forms are never nested in the HTML markup because of the dialog rendering the player form outside through a portal. It's only the synthetic event from react bubbles up on the virtual dom which cause this issue - An submit event dispatched on the player form get bubbles up to team form and trigger the onSubmit handler on both form.

FormContext only helps with accessing the form state and won't help here.

[penx]

I think you can use stopPropagation to solve this?

const [form, fields] = useForm({
  id: useId(),
  onSubmit: (e, context) => {
    e.stopPropagation();
  },
});

edit: not ideal though - caveats

[penx]

I've also encountered this issue today. Our use case is we have a large form, some buttons within it that open a modal.

The modal contains a small form, representing a part of the parent form data. The user can fill this in or cancel out of the modal. This is a different form as, if the user cancels out, it should not affect the data of the parent form.

As explained above, this is valid html as the child form is within the React component tree but not the DOM of the parent form.

We make use of useInputControl's change to update the parent form when the modal form is submitted.

We want to use conform for both forms to keep validation and data structure consistent.

I have't yet found a solution other than using e.stopPropagation.

Other things I've tried that don't seem to work but may be worth further research:

• setting form={form.id} on the submit button
• removing the type=submit from the button and calling conformFormProps.onSubmit directly

[edmundhung]

Nested form tag is a bad practice in general so it is probably better to avoid it even your Dialog might render it outside. Conform has full support of form attribute and is utilizing the formId generated to make sure all your inputs and intent button works no matter they are enclosing within the form tag. You should be able to keep it working like this:

export function Component() {
  const [form, fields] = useForm({
    // ...
  });

  return (
    <>
       <Form {...getFormProps(form)} />
       <input {...getInputProps(fields.example)} />
       <button form={form.id}>Submit</button>
    </>
  );
}

I am converting this to an discussion since the issue wasn't a bug in Conform.

[marilari88]

hi @edmundhung your approch is a nice escamotage for the issue I reported, but I found a problem with the onChange event of the form element. It seems like it is not triggered by changing the inputs outside the form tags