Material-ui: [SelectInput] Allow selected to be chosen with non-strict equality

[fzaninotto]

Problem (short story)

Detection of the selected choice in SelectInput uses strict equality (===) with no option for a non-strict equality fallback. This prevents value initialization from the query string (which isn't strongly typed).

Context (long story)

In an admin, I wrote creation form for Comments. It uses a <TextField select> to display the post_id, which is a foreign key to the related Posts. The possible choices are under the shape <MenuItem value={12}>Lorem Ipsum</MenuItem>. So far, so good.

I wrote a button linking to this form, setting the URL query string as ?post_id=12. The form parses the query string as { post_id: "12" }, and uses this object to initialize the form values. However, when I click on the button, the related post isn't pre-selected.

The problem lies in https://github.com/mui-org/material-ui/blob/b3564a767135b933146f7fe73e3a34b14950c782/packages/material-ui/src/Select/SelectInput.js#L230-L235: it uses strict equality (===) to check if one of the children matches the value. But since the post_id comes from the URL, it's a string (e.g. '12'), while the select choices use number values from the persistence (e.g.12`).

Requested Change

I need to be able to tell the SelectInput (and therefore TextField as well) to use non-strict equality for value selection.

Miscellaneous

• [x] This is a v1.x issue (v0.x is no longer maintained).
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

| Tech | Version |
|--------------|---------|
| Material-UI | v1.2.0 |
| React | 16.3 |
| browser | Chrome |

[oliviertassinari]

@fzaninotto Interesting issue. Of course, you can always normalize the data on React Admin side. Still, I'm eager to see how the native implementation behaves. I think that we should make them (native, non-native) identical. I'm gonna try/test that and see how we can move forward.

[oliviertassinari]

All green for me, it does work this way for the native select.

[mbrn]

@oliviertassinari I can add a property that changes the behaviour of equality as strict or non-strict. What do you think?

selected = (value === child.props.value && child.props.useStrictEquality) || value == child.props.value;

Is it a appropriate solution? If it is i can code & test it.

[oliviertassinari]

@mbrn Why do you want to add a property? Should we just change the behavior? But it's not something I would change in a patch release, for sure.

[mbrn]

@oliviertassinari I just want to solve the problem. may We solve this bug for next minor version?

[oliviertassinari]

@mbrn The next release will be a minor. We are good to go :).

[mbrn]

@oliviertassinari :). I will solve this problem by adding the property. Is it appropriate?

[oliviertassinari]

The strategy is to make the native and non-native implementations as close as possible. What's the use case for useStrictEquality?

[mbrn]

I don't know. But we have at least one case:). Do you mean that this is not appropriate solution to strategy?