Standardize Components with options

Summary

There are various ways to present a list of options to users, each with its own use case. Some common choices include Autocomplete, Select, Radio Group, Checkbox Group, Button Group, and Tabs. While they serve different purposes, they all ultimately allow users to make a selection from a given list.

To improve the developer experience, I’d love to see a more consistent API across these components. For now, I want to focus on two key differences, though this idea could be extended further.

Standardized API for Options

Currently, different components handle options inconsistently. For example, Autocomplete accepts an options prop along with getOptionKey and getOptionLabel, while Select requires its options to be passed as MenuItem children. Instead, all these components—Autocomplete, Select, Radio Group, Checkbox Group, Button Group, and Tabs—should support a unified API with options, getOptionKey, getOptionValue, and renderOption. This would streamline usage and improve maintainability.

Flexible Value Handling

Another inconsistency lies in how selected values are managed. In a Select component, the value is just the key of the selected option. However, an Autocomplete requires the entire object. In real-world forms, relationships between data often require pre-filling fields with default values, which can mean fetching additional data just to display an Autocomplete's value properly. To address this, these components should support both approaches:

• One mode where they accept and return the entire object (onChange provides the full option, and default values must be full objects).
• Another mode where they work solely with keys (onChange returns only the key, and default values can be set with just the key).

Standardizing these aspects would make working with these components far more intuitive and flexible across different use cases.

Search keywords: select,autocomplete,tabs,groups