Change of dirtyFields logic after 6.14.0

[OlehRb]

Hi @bluebill1049 , first of all, thanks for this amazing library, it's been a real pleasure working with it so far.
However recently, we've faced with a minor issue, which affects logic of our apps

Description
As of version 6.14.0 the logic behind dirtyFields and isDirty from useForm / useFormContext seems to be changed quite drastically.

Before 6.14.0 it worked in a following way:

Screen.Recording.2021-01-11.at.18.20.51.mov

But, from 6.14.0 it started working in a completely different way:

Screen.Recording.2021-01-11.at.18.22.38.mov

So, previously we relayed on this behaviour in order to define if user changed anything in the form in order to prevent accidental redirects

Was it an intentional change of behaviour?

To Reproduce
Steps to reproduce the behaviour:

1. Go to
2. Make sure you are using version 6.14.0 or 6.14.1 (the most recent once, at the time of bug report)
3. Enter any value in one of the fields
4. Check that output for "DirtyField" shows true for the altered field
5. Clean the touched field
6. Check that output for "DirtyField" still shows previous state

Expected behaviour
On step 6 "DirtyField" the altered field should be removed from the list of dirtyField

Desktop (please complete the following information):

• OS: MacOS Big Sur 11.1
• Browser: Chrome
• Version: 87

If you need any additional info about the reported issue, please, let me know

[bluebill1049]

you will need to supply defaultValues to make it work correctly with dirty fields. This was fixed by quite a few bugs which is a result of us predicting the default value to be an empty string.

one of the bug below:
🐞 fix #3261 dirtyField with object or array value compare (#3262) merged around Oct 2020

so for isDirty and dirtyFields should always supply a defaultValue for us to do the comparison to avoid issues.

looks like the doc only mentions the need for isDirty, I will include that info in the dirtyFields as well. I know this is not convenient, but as the lib grows we need to seek a more stable and safe approach.

[OlehRb]

@bluebill1049 , thanks for a super fast response
Yep, it looks like, providing of defaultValues makes isDirty and dirtyFields work as expected

I am gonna close this issue

[bluebill1049]

No worries, buddy.