[DropDownMenu] Display the first item in case there's no one with the corresponding value

[zalmoxisus]

• PR has tests / docs demo, and is linted.
• Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
• Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

Like for html select tag, display the first option in case there's no one with the corresponding value. Useful for migrating from vanilla <select value=.../>, also when having dynamic options it wouldn't be effective to traverse the array twice to identify if the value in present. Just displaying an empty element as before doesn't look like a reasonable solution.

[oliviertassinari]

@zalmoxisus That sounds like a great idea. Could you add a simple unit test for this behavior? Thanks!

[zalmoxisus]

@olegberman, sure, you can squash the commits. ESLint warns for react/no-string-refs also on master. Should I add this pr on next branch?

[oliviertassinari]

@zalmoxisus Thanks, warnings aren't blocking. You must have missed this one

/home/travis/build/callemall/material-ui/src/DropDownMenu/DropDownMenu.spec.js
32:1 error Trailing spaces not allowed no-trailing-spaces
The master branch sounds better for this fix.

[zalmoxisus]

@oliviertassinari, fixed. Thanks!

[oliviertassinari]

@zalmoxisus Thanks!

[iPurpl3x]

Hi, I just installed the update and this new feature really annoys me. It's strange how the default label is overlapping the floatingLabelText. Also by adding this feature, there should be an option to disable it because in my case, I don't want anything to be displayed by default, only the floatingLabelText.

[GuillaumeCisco]

I agree with @iPurpl3x the first option is displayed, but not mapped as the value.
Also the hintText is overlapping.
This change is critical, and we cannot use it in production...
It is referred here #4891
A quick fix should be having a param for not enabling this feature, in order to have the precedent behavior.

[zalmoxisus]

I'm really sorry about that, guys :-/
I didn't take it into consideration as I don't use labels.

What do you think of having this only when floatingLabelText is not specified? So we'll avoid empty select boxes as this pr was intended for. @oliviertassinari, should I make a quick PR with that?

[iPurpl3x]

Yep, great idea !

[GuillaumeCisco]

I don't think it is the right solution @zalmoxisus.
It doesn't have to be dependent of floatingLabelText. Because if you don't want to use floatingLabelText but use hintText, it will not work.
Allowing empty select box is critical !!! Sometimes, you want to create a form with unrequired fields.
It doesn't matter if the user did not filled this field represented by a SelectField. Furthermore, the user should be allowed to reset this field to an empty field.
The old SelectField was almost working well... Except the fact, we could not clear it without adding a new component allowing to clear this field (as for DatePicker).
The empty feature should quickly come back.
Right now, I cannot use this field in production, it's a real pain, as 0.15.3 fix a lot of bugs.

[bramick]

From an interaction and UX perspective I agree with @GuillaumeCisco thoughts. The concern here to is the only distinction from a dropdown item actually being selected and just displaying the default first items is the presence of a floating label. That's not good because it's harder for a user to understand what is and isn't actually selected. If you're going to display something as a default, instead of blank at a minimum, it should be constant on all versions of a dropdown. For ex the old style of -- Select --.

That being said I don't believe this aligns with the thinking behind Material Design. If it was these would have it:
https://material.angularjs.org/latest/demo/select
https://elements.polymer-project.org/elements/paper-dropdown-menu?view=demo:demo/index.html&active=paper-dropdown-menu

[oliviertassinari]

@zalmoxisus Regarding how to fix this issue properly.
Aside from what the other projects are doing, I haven't seen much information in the Material Spec about the expected behavior.

Without much information, I think that we should be as close as possible to an HTML select.
E.g. In the docs example, I think that we miss one child:

<MenuItem key="" value="" primaryText="" />

However, this PR is definitely introduction a regression and my suggestion is a breaking change.
Let's fix #4891 first 👍

[GuillaumeCisco]

What is the best?
Following html spec that says a select should not be empty? => Solution : like before, juste use the SelectField with another component that will clear the value.
Or Having a SelectField with the first element set to an empty value?

[clayne11]

It makes perfect sense for me to allow a DropDown or SelectField to be empty. In a form, I want to force the user to fill out all of the fields. I don't want to set defaults because I want the user to actually enter the value themselves, and if they don't enter one my form validator is going to ensure that they enter a value into it.

If you populate the field with a default value it could allow users to accidentally pass over a pre-filled field with the incorrect value. I want users to be forced to interact with the SelectField to ensure they put in the right value.

[bramick]

It makes perfect sense for me to allow a DropDown or SelectField to be empty. In a form, I want to force the user to fill out all of the fields. I don't want to set defaults because I want the user to actually enter the value themselves, and if they don't enter one my form validator is going to ensure that they enter a value into it.

If you populate the field with a default value it could allow users to accidentally pass over a pre-filled field with the incorrect value. I want users to be forced to interact with the SelectField to ensure they put in the right value.

This is my fundamental issue as a UXer as well.

[oliviertassinari]

I have posted some though regarding the direction I think we should follow #4891 (comment).