Skip to content

Proposal: TextField as a Composable component for various field types #2416

Description

@newoga

Hi all,

Wanted to get your feedback on this, (this would probably be a pretty significant change). Based on the material design specification , In an attempt to summarize what a Text field can be, a Text field is one of the following types:

  • Text input (similar to <input /> for single-line or <textarea /> for multi-line)
  • Dropdown control (similar to a <select />)
  • AutoComplete control

In addition, Text fields can optionally have the following attributes (note, I bolded the ones we don't currently support yet):

  • Single-line vs Multi-line
  • Floating text
  • Hint text
  • Character counter
  • Left icon (that also changes color when focused)
  • Full-width vs non-full-width
  • Scrollable vs non scrollable
  • Auto capitalization support
  • Dense vs non-dense mode
  • Disabled state

I think seems more natural that the <TextField /> component manages all of the attributes of the control (such as error, hints, floating labels, etc.), not the underlying type of the control (whether it is a text, dropdown, or auto complete).

Right now, our <SelectField /> and <AutoComplete /> components wrap a <TextField /> and a set of other components with it such as a DropDownMenu for the <SelectField /> or Menu and MenuItem for the <AutoComplete />. This forces us to create additional React PropType on the SelectField and AutoComplete to pass to the underlying TextField for it to be styled properly.

I am proposing that we invert the composition such that a <TextField /> could contain various types of controls. For example:

Examples

/* This could be a standard text field where the value is bound to an input */
<TextField ...textFieldProps>
   <TextInput />
</TextField>
/* This could be a text field that allows the user to drop down and select options */
<TextField {...textFieldProps} >
  <Select {...selectProps} />
</TextField>
/* This could be a text field that allows the user to type and select from a list of options based on search input */
<TextField {...textFieldProps} >
  <AutoComplete />
</TextField>

In addition we could have a prop that manages the underling type with reasonable defaults...

<TextField {...textFieldProps} type="text" /> // This would create a default child TextInput component
<TextField {...textFieldProps} type="select" /> // This would create a default child Select component
<TextField {...textFieldProps} type="autocomplete" /> // This would create a default child AutoComplete component

This would greatly reduce the number of PropTypes on each these control components, and make the API a lot more predictable for consumers of the API. For example, users would know that if they how to use a <TextField /> component for a text input, they know how to use it for a select field as well. From a framework maintenance stand point, if we add support for new prop types, we don't have to worry about extending support to the other types. They will get them automatically.

Sorry for the long explanation. Let me know what you think...

Metadata

Metadata

Assignees

No one assigned

    Labels

    scope: selectChanges related to the select.type: new featureExpand the scope of the product to solve a new problem.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions