Falsy values in select, radio fields

[tejasahluwalia]

Hey guys, so for select and radio fields, if there's a falsy value set as either the value (in options) or defaultValue Payload throws an error: Collection -> Field -> "value" does not match allowed types

I feel like this could maybe be in the docs? What would be the best way to handle this? Because I didn't get any TS error so it was a little difficult to narrow down exactly what was happening. Also, I'm not sure what other fields this might apply to.

[DanRibbens]

Hey @tejasahluwalia,
I am surprised you aren't seeing a TS error in your config if you have it typed. Note the OptionObject that is applied to Options for the Select and Radio fields is currently strict about that.
{
label: string
value: string
}

If you defined your collection as a CollectionConfig or the fields as Field[] from payload, then the ts error for your field should be visible:

I looked at widening the type to allow for an option: { value: false, label: 'false'} and the backend seems functional, but the frontend component on the admin UI side is not. It would take some additional changes to allow boolean in the select and radio fields. I'll defer to @jmikrut on how we might address the UI issues if this is a change we want to make.

For your solution would you be able to have values/defaultValues of empty string: value: '' as the falsey option?

Feel free to share your field config if it aids in the discussion.
What do you think?

[DanRibbens]

Here is a branch where I attempted the changes: https://github.com/payloadcms/payload/tree/feat/field-options-boolean
It would need the UI to be worked on and additional changes for GraphQL.

[jmikrut]

Hey @tejasahluwalia and @DanRibbens —

One other consideration here is that GraphQL enums are used for radio and select values, and those need to be represented by a string, which creates some weirdness when using options other than string values. We'd also need to make sure that string representations of enum values are unique. Meaning... if we auto-generated them from the value, we could stringify true to 'true', but if the user had two options that would be stringified as the same value, everything would get wild.

This may all likely be able to be worked around, but our API currently specifies select and radio option values as strings.

Should we look into changing this further?

[tejasahluwalia]

Thanks for the quick replies guys.

Just to clarify, I do get the TS error if I set the value: false but not when I tried to set value: '' or defaultValue: [] (which I tried when I was using a select with hasMany). Both resulted in errors.

I don't know if this really needs a solution so to speak, it's not really a big issue because I can just set an option with, for example: { label: 'None', value: 'none' }, do my check client-side ( return value === 'none' ? null : value ) and move on. I just thought that the docs should say that empty strings/arrays are not allowed if TS can't detect them. I'd be happy to add these lines and make a pr if you guys are good with that.

[DanRibbens]

Thanks for adding more details. We're always open to reviewing community PRs if you see ways to improve docs or code.

Checking it out further, the validation should not allow value: '' as it breaks the UI and isn't assignable in GraphQL. I've opened a PR to address this getting past config validation: #311. With this you will get an error on startup when there is an option with value: ''.

For the defaultValue: [], I don't see any errors and as far as I can tell the behavior the same as leaving it undefined.

We already have a note regarding option values for radio and select fields that I think is still pretty accurate and now with the config validation change, I feel like it is pretty well covered.
Would you agree?