Form state dirty does stays true when cancelling the selection of a file

[FernandoFigueroa]

Describe the bug

On an input type file, when cancelling the selection, the value of the registered fields goes from blank|null|undefined to a FileList with length 0, since we can't initialize something with a FileList, i guess that means that like the new value is different from the initial one, the field remain dirty.

I tried to workaround by using dirtyFields, checking that if the field was there and no value is set, i delete it from the set, however, that does not update isDirty.

I have it working by replacing the formState.dirty check on my submit button with:

 const formDirty = () => {
    if (dirtyFields.has('fileInput')) {
      const { fileInput } = getValues();

      if (!fileInput || !fileInput.length) {
        dirtyFields.delete('fileInput');
      }
    }

    return Boolean(dirtyFields.size);
  };

That basically relies on dirtyFields.size, but i guess that is something should be handled internally.

To Reproduce
Steps to reproduce the behavior:

1. Go to: https://codesandbox.io/s/react-hook-form-useform-template-qh1r8?file=/src/index.js
2. Click on "choose file"
3. Click cancel on the browser upload dialog
4. See the submit enabled, the form is dirty

Codesandbox link (Required)

https://codesandbox.io/s/react-hook-form-useform-template-qh1r8?file=/src/index.js

Expected behavior
The form should not be dirty, button should not be enabled.

Desktop (please complete the following information):

• OS: Mac
• Browser: Chrome
• Version: Latest

[bluebill1049]

I did investigate this issue, looks like it will be easier in the application level, than in the lib. It's hard to compare the diff with FileList, because defaultValue will be always different from what user has changed.

so here is my suggestion/solution.

<input type="file" name="file" onChange={(e) => {
  if (e.target.value.length > 1) {
    setValue('file', e.target.value);
  } else {
    setValue('file' , '');
  }
}} />

I haven't got time to test it, but let me know if this works for you.

[FernandoFigueroa]

Thanks @bluebill1049, i think your suggestion did not do the trick:

https://codesandbox.io/s/react-hook-form-useform-template-irk0o?file=/src/index.js

I agree that at application level is easier, actually, the solution shown on my first comment works well, however, i think we first need to determine if the form is actually dirty or not by definition.

If it is, then we definitely need to come up with something to make the library return the correct state, or we'd end up with another report like this one.

If it's not defined as dirty, then i might be doing something wrong when implementing the library and we probably should point it out somewhere, again, to avoid reports related to this.

Hope this helps, thanks!

[bluebill1049]

Take a look this CSB: https://codesandbox.io/s/react-hook-form-useform-template-l9666?file=/src/index.js

this was what i suggested above.

[FernandoFigueroa]

Ok, that worked there, thanks!

That's way better than my solution, since i'm not modifying dirtyFields or any other computed stuff however, is not working for my current scenario.

Should we add a note somewhere about this? or maybe work on a solution that works for file inputs and basically remove the need of manually re-setting the value?

If you think some change or note is needed, i can work on it if you point me in to the direction we'll follow.

Thanks again!

[bluebill1049]

however, is not working for my current scenario.

so it's still not working for your use case? may i have some more detail?

Should we add a note somewhere about this? or maybe work on a solution that works for file inputs and basically remove the need of manually re-setting the value?

I don't think we have an easy solution for this since FileList is an immutable object, which means it's impossible to set a defaultValue which match the user when not select a file. However, we can introduce logic inside the logic to encounter this issue, but it's a lot extra check which probably much easier to do at applicant level as I suggested above.

[FernandoFigueroa]

I think is does not work for me yet because i think i don't have the same library version, and because we are using some validation for the file type, also is a big component and i don't have the capacity at the moment to refactor, so that'll be in a while.

So, what do you think of adding something on the docs about this issue? like a caveat or something that help people implement the specific case of an input file to avoid the scenario described?

[bluebill1049]

will add this into a FAQ question. 👍