React-final-form: [improvements] List of the form disabled fields

[BaptWaels]

What is the current behavior?

At submission, we don't have the list of disabled fields. We need to store it elsewhere.

What is the expected behavior?

We could imagine adding the props disabled to the Field component. We could keep a list of disabled fields which could be accessible at form submmission.

ex: We could easily prevent sending the disabled fields to the API.

const onSubmit = async (values, form) => {
  const disabledFields = form.disabledFields; 

  // Extract the disabledFields from values below with .filter
};

[erikras]

This is funny, because it's the standard browser behavior when doing a regular browser submit. It's bitten me many times over the years where I _wanted_ a disabled field's value, and had to create an <input type="hidden"/>

disabled is a bit of field "state" (?) that I've never seen a form library manage. It could certainly be done with a custom (not part of this lib) HOC that wrapped both <Form> and <Field>. Could easily imagine it as a companion lib.

[BrandonWilliamsCS]

I was a bit shocked to realize that disabled fields were not excluded from the submitted value.

To the extent that [react-]final-form builds on top form semantics (rather than changing or replacing), ignoring the disabled state of fields sure feels like a miss. Like you said, @erikras, it's standard browser behavior to drop them! I do understand that "disabled" is only on the edge of what's considered form state, but it's not as though this is an obscure, personal use case. It's how forms have behaved for over a decade, and it's how I (and surely countless other developers) have been conditioned to use it.

I would like address your points above:

It's bitten me many times over the years where I wanted a disabled field's value, and had to create an <input type="hidden"/>

If you WANT a field's value to show up on submit, it's not truly a "disabled field"; it's probably actually a readonly field. Or perhaps it's not a field at all! A value that comes from outside of the form should probably not be stuck into the form in the first place. But otherwise, readonly and/or hidden are the correct choices.

a bit of field "state" (?)

Maybe disabled isn't _per se_ a part of the form state, but it certainly _impacts_ the state of the form, semantically. Pure html forms don't validate disabled fields or include them in the body of their POST requests. It's as important as "name" is when generating form value!

that I've never seen a form library manage.

I don't know how you define "form library", but the Angular form stuff honors disabled status on submit. In any case, you don't have to "manage" disabled-ness so much as react to it as necessary for the sake of maintaining form behavior. Again, it's like passing in the name and building the full value from it.

Could easily imagine it as a companion lib.

I think, because it's about maintaining standard browser behavior, this feature really belongs in the primary library. I can't see myself _not_ wanting to use it... and I would much rather have to deal with manually re-incorporating only-kinda-disabled fields/data than I would with manually excluding actually-disabled fields. Perhaps, for backwards compatibility, this should come with an opt-in flag.