Description
Duplicates
- I have searched the existing issues
Latest version
- I have tested the latest version
Summary 💡
Allow use of styleOverrides in custom variants so we can target and theme component parts (e.g. root, listbox) that are not accessible by specificity from root.
Examples 🌈
Global component overrides can theme component parts via styleOverrides.
const theme = createTheme({
components: {
MuiAutocomplete: {
styleOverrides: {
listbox: background: 'red';
},
},
},
});However, when creating new component variants you are put into root.
const theme = createTheme({
components: {
MuiAutocomplete: {
variants: [
{
props: { newVariant: true },
style: {
// how do I theme MuiAutocomplete-listbox as it isn't enclosed by root?
},
},
]
},
},
});The current workaround is to use the global style overrides syntax with styleOverrides and a callback with ownerState. This results in variant logic in two syntaxes and spread outside the variants array.
const theme = createTheme({
components: {
MuiAutocomplete: {
styleOverrides: {
// component variant logic mixed with global
listbox: ({ ownerState }) => ({
...(ownerState.newVariant === true && {
background: 'red',
}),
}),
},
variants: [
// other variants ...
]
},
},
});I propose we allow the use of the styleOverrides syntax with custom variants.
- Cleaner than the callback syntax
- Keeps variant logic in the variants array
- Reuses
styleOverridessyntax - Cleaner targeting of component parts instead of drilling through CSS specificity
const theme = createTheme({
components: {
MuiAutocomplete: {
variants: [
{
props: { newVariant: true },
styleOverrides: {
listbox: {
background: 'red',
},
},
},
]
},
},
});Motivation 🔦
MuiAutocomplete uses several parts by portal that are inaccessible via CSS specificity from the root component. By allowing the use of styleOverrides in the new component variants we can target and theme those parts just as we do in global style overrides. This avoids putting variant logic in callbacks outside of the variants array.