[Radio] Fix disabled state styling regression

[mnajdova]

Fixes #43588

[mui-bot]

Netlify deploy preview

https://deploy-preview-43592--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 34a9162

[oliviertassinari]

Tricky, if we want the customization experience to be consistent with the other components, e.g. Button, it seems that adding the disabled style in

material-ui/packages/mui-material/src/Radio/Radio.js

Line 80 in f8b2251

[`&.${radioClasses.checked}`]: {

would make more sense. But the real question is what's better DX between the two options?

[mnajdova]

Yeah, my first attempt was to not to do this, with 064907e, but the problem was that we will need to use the useFormControl hook here as well, while it is still used in SwitchBase to ensure we have other right disabled value.

In the end that may be the best out of the two possible solutions. I will update the PR today.

[mnajdova]

I've updated the PR to not change the specificity.

[DiegoAndai]

Why only read the value if undefined?

[mnajdova]

Because the prop should take precedence over what comes form the form field context.

[DiegoAndai]

Right, my bad 😅 I got confused and thought we were checking typeof muiFormControl.disabled === 'undefined'

[DiegoAndai]

(Just for the record):
Before: https://codesandbox.io/p/sandbox/festive-aj-l83k4l?file=%2Fsrc%2FDemo.tsx%3A10%2C26
After: https://codesandbox.io/p/sandbox/damp-wave-d8gdvk

---

@mnajdova, do you know how this broke?

[mnajdova]

@mnajdova, do you know how this broke?

@DiegoAndai can you clarify what you mean? The before primary style on the radio item is not expected, this is what the PR fixes. Unless there is something else. See v5: https://codesandbox.io/p/sandbox/staging-violet-dh3r6m?file=%2Fpackage.json%3A21%2C33&workspaceId=836800c1-9711-491c-a89b-3ac24cbd8cd8

[DiegoAndai]

@mnajdova I mean: How was this bug introduced? Did we miss something when migrating to the variants API?

I'm trying to understand what was the change that introduced the regression to see if there might be similar issues elsewhere.

[mnajdova]

I'm trying to understand what was the change that introduced the regression to see if there might be similar issues elsewhere.

Typically previously we were adding the disabled style last, however, now that we have variants, the variants are being processed after the "default styles" always. In practise this means, that previously we had:

const A = styled()({
  // this is going to be added first
  '&.checked': { 
    // checked styles
  },
  // this is going to be added second, so it always wins
  '& .disabled': { 
    //disabled styles
  },
})

And now with the changes:

const A = styled('div')({
   // this is going to be added first as part of the default styles
  '& .disabled': { 
    //disabled styles
  },
  variants: [{
    props: { color: 'primary' },
    style: { 
      // this is going to be second and because it has the same
      // specificity, wins over the disabled styles
      '&.checked': { 
        // checked styles
      },
    }
  }]
})

Does this helps explain the issue?

[DiegoAndai]

Does this helps explain the issue?

It does! thanks 😊