-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: TextField as a Composable component for various field types #2416
Labels
component: select
This is the name of the generic UI component, not the React module!
new feature
New feature or request
Milestone
Comments
I really like your proposal. Composable Components any day! |
This was referenced Dec 10, 2015
7 tasks
oliviertassinari
added
the
component: select
This is the name of the generic UI component, not the React module!
label
Mar 26, 2017
We have been implementing something close on the v1-beta branch: <FormControl className={classes.formControl}>
<InputLabel htmlFor="name-simple">Name</InputLabel>
<Input id="name-simple" value={this.state.name} onChange={this.handleChange} />
<FormHelperText>Some important helper text</FormHelperText>
</FormControl> And we should continue following that direction with #5716 |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
component: select
This is the name of the generic UI component, not the React module!
new feature
New feature or request
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 aDropDownMenu
for the<SelectField />
orMenu
andMenuItem
for the<AutoComplete />
. This forces us to create additional ReactPropType
on theSelectField
andAutoComplete
to pass to the underlyingTextField
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
In addition we could have a prop that manages the underling type with reasonable defaults...
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...
The text was updated successfully, but these errors were encountered: