keepDirtyValues works weird if you have switchable tabs with registered inputs

[olegmashalanchuk]

I have a very complex app where I receive data from backend, group it and create tabs for each group.
In parent component I generate one object with values and set it as defaultValues.
When user switches between the tabs he can put some values to inputs generated from backend data or add another one. Adding new input will trigger db interaction for insert on a backend which will return a new input object with id and it will be added to the form using reset(obj, keepDirtyValues: true);

When user adds in one tab n numbers of fields - everything works fine. But if he/she puts some values to inputs in a tab 1, then select tab 2 and there will add more than one new input it will erase dirty values from the tab 1. But most interesting that formState.dirtyFields still will show inputs from tab 1 as dirty but with the initial values. And it happens only if there will be more than one data update. So, if user

1. put some value on a tab 1
2. switched to tab 2 put some values
3. added new input on tab 2
4. switched back to tab 1
5. switched back to tab 2
6. added new input on tab 2
7. 4. switched back to tab 1
8. .....
   in this case everything works fine. But if he adds more than 1 new field - draft values disappears.

Is it correct behaviour that reset(keepDirtyValues) works only on first call if input is not visible?

[leapful]

@olegmashalanchuk

Method reset() will work even if input is not visible display: none. It might not work correctly if your visibility is applied by mounting/unmounting the input.

Based on your description, it seems like your Tabs component is only render active tab (a.k.a mount/unmount tab based on its active status). A workaround for this case is to switch to visibility by CSS display: none to keep reference on input field.

[IanVS]

Should this be considered a bug? I cannot easily change the architecture of my tabs, but I still need to be able to reset some form defaults without changing dirty fields. I think either this limitation should be made more clear in the docs, or (even better) it should be fixed so that it doesn't matter how tabs are being shown.