Details of bundle changes

Generated by 🚫 dangerJS against 3cdb209

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.

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

yarn docs:api will take care of it

Codemod like this + test

Or modify it to support both use-cases

@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.

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

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

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

@mbrookes @oliviertassinari Please take a look, thanks!

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.

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.

One more BC done 🙏 @petyosi thanks