-
-
Notifications
You must be signed in to change notification settings - Fork 380
Description
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) => ReactNodefor the "simple" case, maybe rename it to be the equivalent ofgetOptionLabel(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