Skip to content
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

incorrect isDirty values in formGroups #9365

Closed
marit970 opened this issue Oct 17, 2023 · 5 comments
Closed

incorrect isDirty values in formGroups #9365

marit970 opened this issue Oct 17, 2023 · 5 comments

Comments

@marit970
Copy link

What you were expecting:
In our use case, we are using multiple groupForms with inputs and want the other group/input to be disabled once the user has started to type something in one of the input fields. I have tried to reproduce this behaviour and created a minimal example with two fromGroups('name' and 'state') with a text input inside each group. When the user types something in the 'name ' field, the other one ('state') should be disabled. And the other way around, when typing something in 'state', 'name' should be disabled respectively.

What happened instead:
Both fields are disabled when starting to type something in one of the fields because of incorrect isDirty values.

Steps to reproduce:

1. Type something in one of the textInputs
2. Note that instead of the other field being disabled, both fields are disabled now

Related code:

Other information:
I have already opened a bug ticket in react-hook-form, but it has been closed there because this is not a part of their API: react-hook-form/react-hook-form#11055

We assume that this is related to the react-hook-form update to v. 7.46.0 (https://github.com/react-hook-form/react-hook-form/pull/10805/commits)

Environment

  • React-admin version: 4.15.0 (the bug also appears in previous versions e.g. v. 4.13.4)
  • Last version that did not exhibit the issue (if applicable): We could not determine this since this issue was probably introduced with the react-hook-form update mentioned above.
  • React version: 18.2.0
  • Browser: Firefox
@slax57
Copy link
Contributor

slax57 commented Oct 17, 2023

Hi,
Thanks for the issue, and for the analysis.

I managed to reproduce, and can also confirm the issue is consecutive to the react-hook-form change you mentioned (released in v7.46.0).

Indeed, the issue disappears if you comment the disabled props. Besides, debugging the form state shows that either field will be marked as dirty by RHF as soon as they have disabled set to true.

We can see it clearly in this sandbox (RHF v7.45.4) vs this sandbox (RHF 7.47.0): the form is considered dirty after clicking the second checkbox, only in the second sandbox.

I must admit I don't understand why they made that change in react-hook-form/react-hook-form#10805.

Anyways, this is a RHF issue, so best we can do is ask to reopen the issue you created, and make it clearer this has nothing to do with the useFormGroup implementation, as it can be reproduced in a RHF only sandbox.
I'll post a message in this direction, but feel free to put a message of your own to give it more strength 😇

@slax57
Copy link
Contributor

slax57 commented Oct 17, 2023

I've left this comment, hopefully they will answer.

I'll close this issue now, since it's not related to react-admin after all.
Thanks again for the report!

@slax57 slax57 closed this as completed Oct 17, 2023
@marit970
Copy link
Author

@slax57 Okay, thank you!

@slax57
Copy link
Contributor

slax57 commented Oct 24, 2023

For anyone having this issue, you can work around it by adding InputProps={{ disabled: true }} to your input, instead of the disabled prop.
This way, the input will appear as disabled for MUI (and will indeed be read only), whereas react-hook-form won't consider it as disabled and will retain its value.

@fzaninotto
Copy link
Member

We've also added support for the readOnly attribute in 4.16.12. Using readOnly instead of required also fixes the bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants