[material-ui][Select][Radio] Please enable the Select Option value and radio buttons to accept any value

[ahmed-saber]

What's the problem?

We are using the react hook form each time we have a different schema and because of that we face issues with MUI example schema accepts boolean values or null and the component that we are using is select that accepts only string | number | readonly string[] | undefined

What are the requirements?

Return the same value that is passed to the select or radio options without conversion to string

What are our options?

Fallbacks that I didn't like and the solution should be fixed from the library why limiting the library to be reusable with different tools

Proposed solution

No response

Resources and benchmarks

No response

Search keywords:

[mj12albert]

we face issues with MUI example schema accepts boolean values or null

@ahmed-saber Can you provide some more details about the form or UI that requires this and what issues you are facing?

[ahmed-saber]

I'm currently leveraging React Hook Form in tandem with Yup, and while these tools offer valuable functionality, I've encountered certain limitations in terms of the available options from MUI. It seems that regardless of the specific technologies I employ, there are constraints that I find noteworthy. I'm exploring ways to navigate and potentially overcome these limitations to ensure a seamless and robust implementation of my project. If you have any insights or recommendations on how to enhance flexibility within this framework, I'd greatly appreciate your input :

An example:

const schema = yup.object({
    chainId: yup.number().nullable(),
    internal: yup.boolean().nullable(),
});

const validation = useForm({
    resolver: yupResolver(schema),
    defaultValues: {
        // I need to add default values
        chainId: null,
        // in case radio buttons will not accept null or even boolean
        // because it should be a string to match the radio button value type
        // internal: 'true',
        internal: true,
    },
});

const {
    control,
} = validation;

<>
    <Select
        name='chainId'
        control={control}
    >
        {/* if I added a number then the onChange event will return it as a string why? */}
        <Option value={1}>1</Option>
        {/* if I added a null value will not accepted and will throw a typescript error */}
        <Option value={null}>1</Option>
        {/* same issue for boolean values and will throw a typescript error */}
        <Option value={true}>Known</Option>
        <Option value={false}>Known</Option>
    </Select>

    <RadioGroup
        name='internal'
        control={control}
    >
        {/* will convert the values to strings why? */}
        <Radio
            value={value}
        />
    </RadioGroup>
</>

I recommend broadening the functionality of the library by allowing it to accept a wide range of values and focusing the validation on the equality of the chosen option. This approach will significantly enhance the library's versatility and reusability. By adopting this strategy, we align with the principles of MUI, empowering users with greater flexibility and freedom in their implementations.

[mj12albert]

@ahmed-saber Are you using Material UI or Joy UI (or Base?)?

It would be better if you could provide a full (yet minimal) repro, you can fork this template: https://mui.com/r/issue-template-latest

[ahmed-saber]

I'm using Material UI

"@mui/icons-material": "^5.14.19",
"@mui/material": "^5.14.20",
"@mui/x-data-grid": "^6.18.3",
"@mui/x-date-pickers": "^6.18.3",

Please check this link and please check the console to see the errors

[DiegoAndai]

Hey @ahmed-saber, thanks for the report!

Select case

This has been discussed: #16065, #40033, #40432. I have the same opinion as #16065:

Even if [a generic Select] works it's still a hidden as cast. TypeScript cannot check if the value types of the children match the value type in the parent as far as I remember. So all you're doing is making it look sound but it isn't.

So the current solution (which I think is the correct one) is to handle it on your code, for example: https://stackblitz.com/edit/stackblitz-starters-zcuec5?file=src%2FApp.tsx

Radio case

This isn't as neatly as implemented as the Select, but following the same logic, you can handle it on your code: https://stackblitz.com/edit/stackblitz-starters-y8x4qs?file=src%2FApp.tsx

Off topic

We might want to implement something similar to the Select's types in Base UI's RadioGroup and Radio components @michaldudak. And then inherit it to Material UI's Radios from Base UI.

[michaldudak]

Right, my intention with the Radio group was to base it on the same primitives (useList) as the Select.

[ahmed-saber]

@DiegoAndai Thank you for your response but It seems that the MenuItem component in your proposed solution accommodates null values, which differs from my current implementation. Additionally, I haven't encountered any type-related issues so far. My primary concern is maintaining the ability to return the exact values passed to the Select or Radio components without any modifications imposed by the library. After all, why opt for Material-UI if it imposes constraints on specific types? I believe our goal should be to preserve flexibility and adherence to the original data passed to these components.

By the way, I'm using MenuItem but I just renamed it to Option

[DiegoAndai]

Thank you for your response but It seems that the MenuItem component in your proposed solution accommodates null values, which differs from my current implementation.

You're correct. My answer was focused on the boolean types and I missed the null request.

The best workaround I can provide at this moment is this: https://codesandbox.io/p/sandbox/40484-workaround-znwvvv?file=%2Fsrc%2FApp.tsx%3A43%2C36

I agree this is not ideal, and it will be improved when we migrate the Select component to be built upon Base UI. That's why I keep this issue open.

It is safe, though, as the value prop is removed from the Menu item anyway (v5.15.9): https://github.com/mui/material-ui/blob/v5.15.9/packages/mui-material/src/Select/SelectInput.js#L413

I think there isn't a way to ensure Menu item value type safety at the moment.

Refactoring to use Base UI will remove the need for the as any cast. It won't change that the user is responsible for providing the correct values for the options, as typescript cannot check prop types on Select's children.

Alternatively, to remove the as any cast, you could do something similar to the null workaround for the boolean values.