You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've found issues with using resetDirty in my project (the issue exists in 5.9.0 and previous versions), when trying to reproduce and test if a newer version would resolve it, I got an even worse behaviour. I'll therefore divide this into two parts, one for my original issue in 5.9.0 and another part regarding ^5.9.1 to latest (version 5.10.0 as of writing).
Original issue found in version up to 5.9.0
When running setFieldValue and resetDirty in the same callback it causes a race condition, that I currently can only solve using a setTimeout to delay the resetDirty. I think it could be beneficial to allow programmatically changing an input value without flipping its dirty state.
The use-case I have is that I want to give a suggested name dependant on another field, as long as the user hasn't modified the input manually. (I'll also allow it to suggest a new name if the user manually cleared the field)
While the setTimeout works as a workaround, I'd propose adding options to setFieldValue so that one can set the value without modifying dirty, e.g.
Note: During this I've only written dirty but in my experience using isTouched and resetTouched gave the same results. Therefore if this were to be implemented, options for both dirty and touched should be considered.
Issue in ^5.9.1 (which as of writing resolves to 5.10.0 as latest)
Invoking resetDirty, no matter a timeout to delay or not, does not reset the dirty state for the field. As #3025 was merged in that version, which changes this code specifically, it might be worth revisiting those changes as a start in debugging.
Note: This new issue only regards dirty and NOT touched state.
What version of @mantine/hooks page do you have in package.json?
First bug: 5.9.0
Second bug: 5.9.1 - 5.10.0
If possible, please include a link to a codesandbox with the reproduced problem
What package has an issue
@mantine/form
Background
I've found issues with using
resetDirty
in my project (the issue exists in5.9.0
and previous versions), when trying to reproduce and test if a newer version would resolve it, I got an even worse behaviour. I'll therefore divide this into two parts, one for my original issue in5.9.0
and another part regarding^5.9.1
to latest (version5.10.0
as of writing).Original issue found in version up to
5.9.0
When running
setFieldValue
andresetDirty
in the same callback it causes a race condition, that I currently can only solve using asetTimeout
to delay theresetDirty
. I think it could be beneficial to allow programmatically changing an input value without flipping itsdirty
state.The use-case I have is that I want to give a suggested name dependant on another field, as long as the user hasn't modified the input manually. (I'll also allow it to suggest a new name if the user manually cleared the field)
While the
setTimeout
works as a workaround, I'd propose adding options tosetFieldValue
so that one can set the value without modifyingdirty
, e.g.Note: During this I've only written
dirty
but in my experience usingisTouched
andresetTouched
gave the same results. Therefore if this were to be implemented, options for bothdirty
andtouched
should be considered.Issue in
^5.9.1
(which as of writing resolves to5.10.0
as latest)Invoking
resetDirty
, no matter a timeout to delay or not, does not reset the dirty state for the field. As #3025 was merged in that version, which changes this code specifically, it might be worth revisiting those changes as a start in debugging.Note: This new issue only regards
dirty
and NOTtouched
state.What version of @mantine/hooks page do you have in package.json?
First bug: 5.9.0
Second bug: 5.9.1 - 5.10.0
If possible, please include a link to a codesandbox with the reproduced problem
https://codesandbox.io/s/mantine-setfieldvalue-isdirty-resetdirty-2dxr3i?file=/src/App.tsx
Are you willing to participate in fixing this issue and create a pull request with the fix
Yes
The text was updated successfully, but these errors were encountered: