Skip to content
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

[Core] Nomenclature #3694

Closed
chrismcv opened this issue Mar 14, 2016 · 3 comments
Closed

[Core] Nomenclature #3694

chrismcv opened this issue Mar 14, 2016 · 3 comments

Comments

@chrismcv
Copy link
Contributor

Derived from #3682

There are a number of inconsistencies with naming in the current library. Some examples include <RaisedButton /> and <FlatButton /> vs <TextField /> and <TextField multiLine={true} />.

We should agree on some guidelines to answer the questions "When is a new property/feature on a component a new component?" and "What should this component be called?"

Some suggestions to trigger further discussion.

  1. Formatting is a component concern, therefore <FlatButton /> and <RaisedButton /> should probably be combined. And the existence of <IconButton /> should be questioned.
  2. Behaviour changes should often make new components.
    a) TextField Multiline should be a different component as the number of lines, and autogrowth probably warrants separation. Most TextField uses won't need this functionality.
    b) Also, <FloatingActionButton /> perhaps has different behaviour, (though we don't currently implement much of that) so should be a separate component.
    c) <ListItem /> has nestedItems and children, which by proxy <MenuItem /> then has.
  3. It would be nice to scope naming of similar components... I quite like <Progress.Linear />, and <Progress.Circular /> as the end product for users of material components. The implementation of this might be too hacky, so <LinearProgress /> vs <ProgressLinear /> should be considered. Also, should <DatePicker /> and <TimePicker /> fall under this categorisation like the material spec?
  4. Material Design Spec has neither <DropDownMenu /> nor <SelectField /> nor <Badge /> nor <LeftNav />
@nathanmarks
Copy link
Member

@chrismcv Thanks mate! Better than the issue I would have cooked up today ;)

  1. 100%
  2. I agree, one of the problems with the current TextField that we all want to address (and we will revisit after 0.15 is that it feels as though you're bringing the entire kitchen sink with you for a simple input.
  3. How do you do that scoping without attaching components as a static property on other components?

@damienfa
Copy link

damienfa commented Apr 5, 2016

About the SelectField, I don't really understand the difference between SelectField and DropDownMenu in terms of "features" ?
Also, AutoComplete component is like a SelectField with auto-select feature... I've missed something ? Isn't it possible to make it an option/props of SelectField ?

@oliviertassinari
Copy link
Member

We have done our best to improve the nomenclature on the v1-alpha branch. Most of the time, we try to the Material Design Specification nomenclature. If you find anything disturbing on that branch, please raise your voice before it's too late with the official release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants