final-form / final-form

🏁 Framework agnostic, high performance, subscription-based form state management

Home Page:https://final-form.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Discrepancy between the various field types when reverted to initial state

ismay opened this issue · comments

commented

Are you submitting a bug report or a feature request?

Feature request (if what I'm mentioning below warrants a change)

What is the current behavior?

I was talking with a colleague about how FF handles a user reverting form values back to their initial value. It confused us a little, since there are some discrepancies between the form field types, and we couldn't figure out why.

So in this codesandbox, which is almost identical to the simple example from the docs, the following field types are removed from the form state when reverted to their initial state by a user:

  • Text input: property removed from state when field is emptied by user
  • Select: property removed from state when option without value is selected
  • TextArea: property removed from state when field is emptied by user

And these remain in the form state:

  • Checkbox: property remains in state (with a value of false) when selected and then deselected
  • Select (multiple): property remains in state (with a value of [""]) when only option without value is selected
  • Checkbox group: property remains in state (with a value of []) when no checkboxes are selected
  • Radio: can't deselect

What is the expected behavior?

I would expect either an explanation in the docs as to why FF behaves this way (I might be overlooking a reason for the current behaviour), or more of an alignment between the field types. So that they for example all stay in the form state, no matter what the user does.

Sandbox Link

https://codesandbox.io/s/elated-grass-epv57

What's your environment?

FF: latest (see codesandbox)
OS/Browser: I'm running macOS Catalina with Firefox 72