[RFC][Select] Rendering the selected value in SSR & during hydration

[mj12albert]

What's the problem? 🤔

Raised in #37, to refine the renderValue API to support rendering Select's selected value in SSR and during hydration

What are the requirements? ❓

• I would expect to be able to render the value to look exactly like a (custom) option
• Avoid breaking changes required of Material UI v6

What are our options? 💡

1. Provide an options prop

useSelect already accepts an optional options param, though it will ignore JSX children

The Select component does not pass (or even accept) options to the underlying useSelect.

Though it may be asking too much from the user, it could be optional for those that need it.

Related - possibly related, raised in this (old) issue, why options aren't provided by renderValue:

const options = [ ... ];

return (
  <Select
    renderValue={value => {
      const item = options.find(option => option.value === value ); 
      return item.label
    }}
  />
)

2. An Autocomplete-like API

Suggested in #37

Autocomplete has getOptionLabel for the simple case of rendering a string (usually when the value and option are the same type), and renderOption that is more like a render prop.

Applying this pattern to Base's Select could look like:

• Keep the renderValue: (selectedValue) => ReactNode for the "simple" case, maybe rename it to be the equivalent of getOptionLabel (e.g. getValueLabel? getValueDisplay?)
• Have a "proper" render prop for the value that provides additional arguments, e.g. ownerState

This may allow more flexibility, but it is quite different from Material UI's current API

Proposed solution 🟢

I think Base UI's Select's current renderValue is already quite sufficient, it has parity with Material UI, and the layout shift issue was fixed

Having two props for rendering the value like Autocomplete doesn't seem worth it for the additional mental overhead of a new prop, and it would deviate more from the current Select APIs

Maybe it would be enough if we pass ownerState to renderValue as a 2nd argument to provide more customization flexibility. At the risk of bloating this too much, we could even additionally accept options and pass that into ownerState as well

Resources and benchmarks 🔗

• https://react-spectrum.adobe.com/react-aria/Select.html#dynamic-collections

[DiegoAndai]

I think Base UI's Select's current renderValue is already quite sufficient, it has parity with Material UI, and the layout shift issue was fixed

The proposed solution looks good to me

At the risk of bloating this too much, we could even additionally accept options and pass that into ownerState as well

I wouldn't take this route until requested by users

[mnajdova]

I think Base UI's Select's current renderValue is already quite sufficient, it has parity with Material UI, and the layout shift mui/material-ui#38796 was fixed

+1, seems like the best option