Fix <ArrayInput> should keep error state on children after unmount#9677
Fix <ArrayInput> should keep error state on children after unmount#9677slax57 merged 1 commit intomarmelab:masterfrom
<ArrayInput> should keep error state on children after unmount#9677Conversation
slax57
left a comment
There was a problem hiding this comment.
Thanks for your contribution, and for the detailed explanation!
AFAICT this goes in the right direction, and fixes the form's behavior to make it more coherent.
I can't think of a use-case where this would be a breaking change, since you already cannot validate the form if the ArrayInput is invalid, even unmounted. This fix simply allows to see the validation error at the correct time.
However I'll request the review of @djhi or @fzaninotto , just to be on the safe side.
Also, it would be nice if you could add a unit test covering this case, so that we don't run into this issue in the future. Can you try adding a new test?
Thanks
|
Seems fair to me, too. I agree this needs unit tests to prove that it fixes something, and that we won't break it in the future. |
004e945 to
ffa6c95
Compare
|
Done! Test fails without the fix and succeeds with the fix. |
<ArrayInput> should keep error state on children after unmount
We have a rather large form, in which we for optimization reasons unmount parts of the form when not visible. This doesn't work to well with
<ArrayInput />however, which clears all state (errors, touched, etc.) when it is unmounted, which both means that the general valid/invalid state of the form is no longer correct.To reproduce:
<ArrayInput />that can be unmounted and some field that can have errors as child<ArrayInput />Here is a reproducible example: https://stackblitz.com/edit/github-ntzyud-hb8uu4?file=src%2Fposts%2FPostEdit.tsx (note that tabbed forms have a similar issue, however that can more easily be worked around in user-space code)
This fix uses the
react-hook-formoptions to keep the state of the<ArrayInput />when it is unmounted.I'm not 100% sure if this might break BC (I think it would be possible to build a form that depends on the current behavior, but I don't think it would make much sense to do so), if that is the case let me now and I'll retarget this PR to the
nextbranch.