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...
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:
<input />for single-line or<textarea />for multi-line)<select />)In addition, Text fields can optionally have the following attributes (note, I bolded the ones we don't currently support yet):
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 aDropDownMenufor the<SelectField />orMenuandMenuItemfor the<AutoComplete />. This forces us to create additional ReactPropTypeon theSelectFieldandAutoCompleteto pass to the underlyingTextFieldfor 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
In addition we could have a prop that manages the underling type with reasonable defaults...
This would greatly reduce the number of
PropTypeson 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...