[BUG] MUI useModalForm() can't edit the same resource ID back to back

[gdongca]

Describe the bug

A edit dialog implemented with useModalForm() will work well if every time I tried to open to edit a different resource id, but will always fail to populate the data if I open the same resource as the last-open one.

Steps To Reproduce

I am using the MUI useModalForm() in a resource list page to to edit selected resource by users. I created a Edit dialog component, and embedded a single instance at the end of the page.

• When I open the modal (action='edit') the first time on a resource id, it was able to read the resource and populate the form with correct data.
• When I opened the modal on the same resource id again (back to back), it failed to populate the form data. All the fields are empty.
• If I tried to open a "different" resource id than the last-open id, it started working again.
• Note: the isDirty state is also not reset between different edit sessions, and it is not consistent with the dirtyFields value.

Expected behavior

I expect that open to edit the same resource back-to-back will still work.

Packages

"@refinedev/core": "^4.57.9",
"@refinedev/mui": "^6.2.1",
"@refinedev/nextjs-router": "^6.2.3",
"@refinedev/react-hook-form": "^4.10.2",

Additional Context

No response

[alicanerdurmaz]

Hello @gdongca, thanks for the issue.
We’ll take a look as soon as we finish our current tasks (in 1–2 weeks at most).
In the meantime, if you'd like to work on this, we'd be very happy!

[JithendraKavala]

Hi, I'd like to work on this issue. Please assign it to me!

[arndom]

You can submit a PR @JithendraKavala, assigning of tasks isn't a thing anymore because people haven't been following up after being assigned.

[gdongca]

I found that if I include the following attributes when calling useModalForm() this problem disappeared. Is this the by design behavior?

modalProps: {
autoResetForm: false,
autoResetFormWhenClose: false,
},

[arndom]

That doesn't seem to be the case.

I tried with the reset form args set to false, and that would only work for your use case when the user just reopens the form without touching the fields of the form previously, i.e no change in form state.

The cause appears to be the useForm hook that updates form values doesn't get called again due to the query having the same data since the ID hasn't changed.

useModalForm calls useForm, here, but since the latter doesn't know if the modal is open/closed, it isn't going to update the form fields with its useEffect since the query result is identical as the resource id is unchanged,

refine/packages/react-hook-form/src/useForm/index.ts

Line 198 in 9420b3f

useEffect(() => {

A possible solution would be to either call reset() whenever the modal opens or give useForm the visible variable, the former may be better to implement...

[gdongca]

That doesn't seem to be the case.

I tried with the reset form args set to false, and that would only work for your use case when the user just reopens the form without touching the fields of the form previously, i.e no change in form state.

It appears that the useForm hook that updates form values doesn't get called again due to the query having the same data since the ID hasn't changed.

useModalForm calls useForm, here, but since the latter doesn't know if the modal is open/closed, it isn't going to update the form fields with its useEffect since the query result is identical as the resource id is unchanged,

refine/packages/react-hook-form/src/useForm/index.ts

Line 198 in 9420b3f

useEffect(() => {
A possible solution would be to either call reset() whenever the modal opens or give useForm the visible variable, the former may be better to implement...

Yeah I saw the same problem. If any value is change but not saved, the next time it will open without resetting the dirty value.

[Woutuuur]

I bumped into this issue as well. Notice that it also happens on the demo page: https://refine.dev/docs/packages/react-hook-form/use-modal-form/#usage (the edit modal demo), so it is not user error.

[arndom]

yh, it isn't user error. The cause is explained here: #6904 (comment)

Got a PR in the works as well.