-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate Material UI components to support theme CSS variables #32049
Comments
Could we suppose that for components that don't use |
I have updated the list. |
Correct me if I am wrong, but I think import { Theme as MuiTheme } from '@mui/material/styles';
declare module '@mui/material/styles' {
interface Theme {
vars: Omit<
MuiTheme,
'typography' | 'mixins' | 'breakpoints' | 'direction' | 'transitions'
>;
}
} |
You are right. Even though, I think some part of the typography is nice to have to be generated as CSS variables but let's do thing one step at a time and neglect the typography for now. I have updated the issue decription. |
I don't think |
It might be early to ask, but do you plan to keep both solutions, add this as an alternative only or will you replace the current provider with the new one eventually? |
Absolutely, yes. The CSS variables support is considered a new feature that developers can opt-in. We don't plan to replace the current one at this point. |
👋 Progress UpdatesMigrationThe migration to support CSS variables in all components is at the finishing line. All issues have been resolved and we can fix all the problems that cause dark mode flicker when you adopt the new provider. TypescriptWe will provide a module augmentation file similar to the lab to augment the theme to have access to the CSS variables. You just need one line in your project. import type {} from '@mui/material/themeCssVarsAugmentation';
// You will be able to see `theme.vars` in all of the APIs eg. styled, sx, useTheme This should work as well if you have custom module augmentation. DocsAfter the migration and the types are done, we will start working on the docs about how to work with CSS variables. There are mental model changes that are different but we believe that it is the right way to go For example: // current
color: theme.palette.mode === 'dark' ? theme.palette.primary.main : theme.palette.text.primary,
// With CSS variables
color: theme.palette.primary.main,
[theme.getColorSchemeSelector('dark')]: {
color: theme.palette.text.primary,
} Using JS condition to switch between colors at runtime will not scale:
Blog postWe will definitely share insights and overviews about what it means for Material UI to adopt CSS variables! |
I've been testing this new provider, works great, but I have a doubt. I wanna use After reading :root {
--md-some-color: ;
}
@media (prefers-color-scheme: dark) {
:root {
--md-some-color: ;
}
} And we change (target: 'dark' | 'light') => `(prefers-color-scheme: ${target})` What do you think? |
@ceopaludetto Thanks for the feedback. Can you explain a bit more about your use case? Providing a minimal CodeSandbox would be great! |
@siriwatknp :root {
--md-some-color: 255 255 255;
}
[data-theme="dark"] {
:root {
--md-some-color: 0 0 0;
}
} But if he chooses "media", the injection will be: :root {
--md-some-color: 255 255 255;
}
@media(prefers-color-scheme: dark) {
:root {
--md-some-color: 0 0 0;
}
} In second option, user loss the ability to dynamic change the theme based on preference inside the application, but he can use without calling I've created two sandboxes, one with data-attribute behavior and another with media behavior, I've used emotion for example purposes, but I tried to replicate CssVarsProvider actual implementation. data-attribute: https://codesandbox.io/s/emotion-data-attribute-rw288w |
@ceopaludetto Got it, yeah it is not possible at this point. Would you mind creating a new issue to discuss further? |
Of course not, thanks for listening, i'll open later |
@siriwatknp This look great! I think there might be an issue with the SnackbarContent. The content color will always be primary text color, which will have poor contrast with the snackbar background color. I think it should be something like |
Even though Also a question regarding the vars provider. Suppose we have a theme object, until this point had my own version of |
Good to hear that! I believe that the
Yes, Before: const theme = createTheme({ palette: { mode: userSelectedMode } });
<ThemeProvider theme={theme}> After: const theme = extendTheme({
colorSchemes: {
light: { palette: { ... } },
dark: { palette: { ... } },
}
});
<CssVarsProvider theme={theme}> Note: I think this diagram describes it really well (more details in #27651). |
Hey, @TimoWilhelm and mui team! We consume mui library and have rather straightforward use of snackbar component
after dependencies update unexpectedly text or success messages changed from white to black. is such side effect possible as result of this PR ? |
@maks-yaremishyn The |
This looks like you have custom styling applied to your To answer your question: No, the PR should not affect the |
A few questions, if anyone is kind enough to answer these
|
@mwskwong Great questions!
For Material UI, NO. We consider CSS variables support as an opt-in feature on top of the default API.
No, omitting the key does not remove the default dark mode styles (that's why it is the default styles). The workaround is to remove the const theme = extendTheme();
delete theme.colorSchemes.dark;
// CssVarsProvider will generate CSS variables based on the object in `theme.colorSchemes`.
<CssVarsProvider theme={theme}> Proof that it works: https://codesandbox.io/s/cssvariablescustomization-demo-material-ui-forked-qfy955?file=/demo.js I will put this in the docs. #33417 |
I noticed the migration task doesn't include lab components. Is that intended to be included some time in the future? |
Sure! I have created an umbrella issue to keep track of it. The contribution from the community is welcome as well. |
@mwskwong We have added support for CSS variables in lab components. It should be available in the next release. |
Maybe a dumb question, but is there some reason not to just mutate the e.g. something slightly more smart but along the lines of theme.vars = theme.vars || theme // ideally pick out only the right stuff here, but this is essentially what the || does elsewhere |
We need your help!
Starting from 5.6.0 we are adding a new experimental API for supporting CSS variables in the Material UI components. You can see more details for this new feature on #27651 or our docs page.
The changes are not breaking so we can safely apply them in the components during the lifecycle of v5.
Initially, the idea was implemented in one component, the Button, but we would need this to be applied to all components. This issue will help track the progress of the migration.
Contribution guides
(theme.vars || theme).*
.docs/pages/experiments/material-ui/css-vars-template.tsx
. Ex. if you pick Accordion component, create the page (docs/pages/experiments/material-ui/accordion.tsx
) and copy the template. Then, import the Accordion and render it on the page.yarn docs:dev
/experiments/material-ui/{component}/
and check the component (it should look the same)Patterns
Straightforward
color manipulation
Some components are using a conditional statement to switch values between modes which causes the flicker issue for SSR application. To fix this, we have provided channel colors to be combined with opacity (thanks to CSS variables, this seems to be the only solution so far).
The channel colors in the theme palettes are
mainChannel
,lightChannel
,darkChannel
andcontrastTextChannel
.List of components
Ready to be picked up
✅ First set is done!
[ ] Pagination[ ] ScopedCssBaselineNeed clarification
These components contain hardcoded values between modes. We will put the guidelines for each of these components and moved them to "Ready to be picked up".
Proposal: #32049 (comment)
The text was updated successfully, but these errors were encountered: