[Select][FormControl] Make outlined variant the default one

[petyosi]

Breaking changes

• [Select] Change default variant from standard to outlined ([Select][FormControl] Make outlined variant the default one #24895) @petyosi
  Standard has been removed from the Material Design guidelines. This codemod will automatically update your code.

  -<Select value="Standard" />
  -<Select value="Outlined" variant="outlined" />
  +<Select value="Standard" variant="standard" />
  +<Select value="Outlined" />

• [FormControl] Change default variant from standard to outlined ([Select][FormControl] Make outlined variant the default one #24895) @petyosi
  Standard has been removed from the Material Design guidelines. This codemod will automatically update your code.

  -<FormControl value="Standard" />
  -<FormControl value="Outlined" variant="outlined" />
  +<FormControl value="Standard" variant="standard" />
  +<FormControl value="Outlined" />

---

Change the default variant from standard to outlined. Rationale in Material Studies: Text Fields. Done for TextField in #23503.

One of #20012

Checklist:

• Change the default variant of the Select component
• Change the default variant of the NativeSelect component better be done in a separate PR, not a small thing, IMO
• Update the Select docs
• Review the variant usage of the FormControl and see if it is safe to change it
• Entry in the migration guide
• Change docs/pages/api-docs/select.json (or maybe it is generated?)
• In the docs, remove all explicit variant="outlined" props
• Where necessary, add variant="standard" to selects who had no variant before
• Codemod like this + test
• Review tests
• Review <TextField select>

@mbrookes - please let me know if I am missing something from the above. FWIW, the biggest inconvenience of the outlined Select is that the label prop value should match the InputLabel text.

• I have followed (at least) the PR section of the contributing guide.

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 3cdb209

[oliviertassinari]

FWIW, the biggest inconvenience of the outlined Select is that the label prop value should match the InputLabel text.

True. I think that most developers use the composed version (<TextField select>). It's handled for them. We have #21782 to better solve this problem.

[mbrookes]

Change docs/pages/api-docs/select.json (or maybe it is generated?)

yarn docs:api will take care of it

[mbrookes]

Codemod like this + test

Or modify it to support both use-cases

[petyosi]

@mbrookes @oliviertassinari I need your advice on how to scope this changeset. This change seems to be triggering multiple related ones. Here's what I am seeing so far:

The Select component obtains its default variant from the parent FormControl, which is "standard" atm. Based on the examples, I assume that a significant amount of users wrap Select in FormControl.

With that in mind, I see two possibilities:

A) Change the default variant of the Select, and leave the FormControl change for a follow-up PR. Smaller and safer, but to put it simply - won't do much, apart from the users who use it without a FormControl. This approach also raises the question of what should be done for the docs page - should all FormControl wrappers get variant="outlined"? Or should we count that the follow-up PR will take care of that?

B) Change the default variant of FormControl to "outlined". This is what I have been exploring so far, but it ripples through several areas - see the argos build failure. The variant change affects the default look of FormHelperText and InputLabel. It also subtly breaks such compositions:

<FormControl ...>
... <Input />
</FormControl>

From what I see, for the above to look correct, Input should be replaced with OutlinedInput.

Maybe there's C) another approach?

FWIW, I am very supportive of outphasing the "standard" variant of selects and inputs. It definitely feels like a usability mistake in hindsight.

[oliviertassinari]

B) Sounds like the best way to go. It does involve diving into multiple parts of the codebase.

[oliviertassinari]

@petyosi How is the effort going? Did you face a blocker?

[petyosi]

Hey, sorry for the delay, Working through the screenshot differences, I will push an update for review this week.

[petyosi]

@mbrookes @oliviertassinari Please take a look, thanks!

[mnajdova]

The changes look great. One thing I am not sure about is, whether the standard variant should still be named standard as it is not a default value. I feel like maybe we should rename to something like underlined variant (or anything else that is not standard, as it not being default value means it is not standard :))

[mnajdova]

Suggested change

	<TextField {...props} variant="standard" />
	<TextField variant="standard" {...props} />

Shouldn't this be the result? Otherwise, we are always overriding any variant being part of props. The same would be applied to the other components if this is correct.

[petyosi]

Your comment seems correct to me - the codemod was originally introduced by @mbrookes and I basically multiplied it.

[mnajdova]

Ah I see, ok let's consider fixing it in a separate PR.

[oliviertassinari]

whether the standard variant should still be named standard as it is not a default value.

@mnajdova If I recall correctly, the name originates from when we introduced the filled, and outlined variant. It likely has this meaning:

a pattern or model that is generally accepted:

https://dictionary.cambridge.org/dictionary/english/standard

It doesn't age well if it's not the default, agree. Should it be enough to make a breaking change? I guess we have to weigh the cost. cc @mbrookes. In any case, I think that it's outside the scope of this PR and should concern a potential follow-up. Personally, I think that it would cost a lot for some value, maybe not enough.

[mnajdova]

I think that it's outside the scope of this PR and should concern a potential follow-up. Personally, I think that it would cost a lot for some value, maybe not enough.

Agree, it is definitely out of the scope of this PR, just thought to mention it as we are making the changes now. So far developers were never typing variant="standard", as it was the default value. Now that it is not a default value, they would need to add it, so my thought was instead of adding variant="standard", they could add variant="underlined". But on the other hand, I get that it may not be work the effort, but let's at least consider it before making the final decision.

Let me update the branch with the latest changes, so we can take a look on the changes & visual regressions better.

[oliviertassinari]

Is there more context on this change?

[petyosi]

without the notched prop, the label was strike through the fieldset border. My guess is that this has always been the case, but the combination (outlined + multiple) was never visible.

[oliviertassinari]

The visual regression test caught this:

[oliviertassinari]

This one might be related as well:

[petyosi]

Good catch on the first one. I was trying to fix the native + multiple + outlined combo. Pushed a fix.

The second one is not related. It is "right" I believe, although it does not look very well. The example itself is quite extreme, as the width is very small (I guess in order to test the wrapping of the chips).

[oliviertassinari]

One more BC done 🙏 @petyosi thanks