useController serializes boolean default values as strings for input[type=checkbox]

[zettadam]

Version Number

7.43.9

Codesandbox/Expo snack

https://stackblitz.com/edit/react-ts-cntuap

Steps to reproduce

I have a form with a couple of fieldsets using custom components:

• QFieldsetOne—group of Checkbox components with register function (uncontrolled, different name)
• QFieldsetTwo—group of Checkbox components rendered by custom ControlField adapter (controlled, same name)
• QFieldsetThree—Textarea and a group of Checkbox rendered by custom ControlField adapter (controlled, different name)

react-hook-form is setting value attribute as a stringified boolean on input[type=checkbox] when using useController hook (QFieldsetThree). This does not happen when using register function (QFieldsetOne) or an array of controlled checkboxes (QFieldsetTwo)

Expected behaviour

I would expect useController to set checked property on field object produced by useController hook and not serialize it as field.value property when it is a boolean.

An example in the official documentation of Checkboxes component use internal state and it might make sense in this case where value is an array, but a group of checkboxes does not necessarily need to have the same name or be indexed, and in those cases react-hook-form is less helpful by forcing a string value for booleans.

BTW, how else should defaultValues be structured or transformed before being passed to useForm hook to work with objects containing properties that are boolean?

What browsers are you seeing the problem on?

Firefox, Chrome, Safari, Edge

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[bluebill1049]

react-hook-form is setting value attribute as a stringified boolean on input[type=checkbox] when using useController hook (QFieldsetThree). This does not happen when using register function (QFieldsetOne) or an array of controlled checkboxes (QFieldsetTwo)

What do you mean by serialised boolean value?

• register with checkbox has our own "opinionated" implementation and is close to native input behaviour.
• useController with headless implementation with your own custom controlled component and the props of your input value is derived by your own component.

[zettadam]

QFieldsetThree is responsible for managing this part of defaultValues:

useForm({ defaultValues: {
   ...,
   finally: {
     active: false,
     ...
   }
}

It producess this HTML output:

<fieldset>
  <legend>Finally...</legend>
  <div class="input-column">
    <label>
      <input name="finally.active" ... type="checkbox" value="false">Are you active? 
    </label>
    ...
  </div>
</fieldset>

useController (used in ControlField adapter) serializes boolean value of finally.active via field object that is spread and results in <input type="checkbox" ... value="false">

NOTE: I override onChange handler coming from field in ControlField adapter, but value is passed as it was created by useController hook

[bluebill1049]

Those are your implementation detail, this is not related to a bug in this library and we don't serialize in the useController hook.

[zettadam]

useController returns field object containing "false" string value in this case... that's not my implementation detail. I'd consider this a bug in useController.

My expectation would be for useController to turn boolean value into checked property automatically—not return "true" or "false" string, but checked property.

[leapful]

@zettadam

This is not a bug of useController. According to HTML specification, the attribute "value" of any <input /> element is always a string value, even in case <input type="checkbox" /> because in some use case, the expected value of checkbox can be enum-like value for example: "red", "green", "blue" ..., not only strict to boolean value.

If you want to get boolean value, you can just apply your overridden onChange with attribute checked of <input type="checkbox" /> element.

Working demo: https://stackblitz.com/edit/react-ts-ixfyvb?file=components%2FControlField.tsx,helpers.ts

[zettadam]

<input type="checkbox" /> does not require a value so saying that "According to HTML specification, the attribute "value" of any element is always a string value, even in case <input type="checkbox" />" is not correct.

"If the value attribute was omitted, the default value for the checkbox is on, so the submitted data in that case would be subscribe=on."

When defaultValues contain properties that are boolean, it means that a form will render a single or a set of checkboxes without a value, just like in the first example on this reference page

My point is that useController returns a string value "true" or "false" for boolean values contained in defaultValues when it is not required.

This is the bug I want to report. You moved it to discussion, essentially hiding it from view and attention I think it deserves.

I think correct implementation of this functionality should be a part of useController

My implementation of a custom Checkbox component takes into account that value prop passed to it is optional. Third-party components will make that assumption, based on HTML standard, as well . useController breaks that assumption and returns a value anyway.

[leapful]

@zettadam

<input type="checkbox" /> does not require a value so saying that "According to HTML specification, the attribute "value" of any element is always a string value, even in case " is not correct.

=> It seems you are mis-understanding my comment. The attribute "value" is always string value according to https://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html meaning no matter what value you set into it, it always try to serialize the value into string. There is no "required" or "not required" mentioned in the comment.

Also noted in the previous comment, there is a case when value of checkbox is used as enum-like value so react-hook-form applies a centralized solution for all cases to use value attribute as a single source of truth to get/set input value therefore data type is always a string.

This is the bug I want to report. You moved it to discussion, essentially hiding it from view and attention I think it deserves.

=> You reported it as a bug but it's not and the behavior is expected, that's why it has been moved to Discussion to discuss more about the solution or workaround.

Third-party components will make that assumption, based on HTML standard, as well. useController breaks that assumption and returns a value anyway.

Sure thing useController hook can follow HTML standard but the value will be string value on but I guess this is not what you expected or many other developers.

If the workaround of using checked attribute to get correct boolean type value does not solve your problem, please share more details about the problem when using it.

[zettadam]

Imagine that defaultValues passed to useForm are set by the server and for some properties, they are boolean. I'd expect useController to inspect that value and not pass it back as a stringified false or true.

const form = useForm({ defaultValues: {
  firstName: 'John',
  lastName: 'Smith',
  active: true,
  canWalk: true,
  canSwim: false
}

const {
  field, // { name, onChange, value, checked, } // you can inspect a boolean value and set `checked` accordingly 
  formState
} = useController({ name: 'active' })

When I submit values, I should not see them as { ..., active: "true" }, I should see { ..., active: true }. But that's not the case. react-hook-form keeps track of active value as string.

These libraries handle boolean values correctly and I don't need to do anything to get it working as expected:

• React-Final-Form example
• Formik checkboxes example

They don't convert initialValues containing boolean properties to strings. React-Hook-Form does, and it doesn't work as expected and it's a bug.

[murtaza-exteme]

@zettadam Facing similar issue, react hook forms serialize those default values which are not registered in as a field. One solution could be to get the values from watch() and then submit it.
btw, were you able to find whats actually causing the bug?