-
Notifications
You must be signed in to change notification settings - Fork 2
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
Docs/css variables material UI #32
Docs/css variables material UI #32
Conversation
mnajdova
commented
Mar 29, 2022
- I have followed (at least) the PR section of the contributing guide.
## Motivation | ||
|
||
There are three main problem that would be solved by using CSS variables: | ||
|
||
1. Dark theme flash on SSR - the light theme is being loaded fist by default, and only after that the dark mode is appearing, causing a flash when opening the page. | ||
2. Bad debugging experience - if you open the dev tools and try to inpect the styles of some element, all you see is the calculated value it receives, without any information of where that value came from. | ||
3. Performance - at this moment, the dark and light themes are considered as different input in the `ThemeProvider`, causing the whole tree to re-render when the theme is changed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need to explain it here, instead link to the issue, RFC would be more concise.
2. Bad debugging experience - if you open the dev tools and try to inpect the styles of some element, all you see is the calculated value it receives, without any information of where that value came from. | ||
3. Performance - at this moment, the dark and light themes are considered as different input in the `ThemeProvider`, causing the whole tree to re-render when the theme is changed. | ||
|
||
## Solution |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Solution | |
## Usage |
I think "Usage" is more direct because we are explaining how to use?
At this moment, the API does not require any breaking changes for the Material UI components, however it depends on using a new experimental provider for the theme, called `Experimental_CssVarsProvider`. | ||
Except for providing the theme in the inner React context, this new provider has as a responsibility to generate CSS variables out of all tokens in the theme that are not functions, and make them available in the context. | ||
All these variables, are available under a key in the theme, named `vars`. | ||
The structure of this object is identical to the theme structure, the only difference is that the values represent some css varaibles. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The structure of this object is identical to the theme structure, the only difference is that the values represent some css varaibles. | |
The structure of this object is identical to the theme structure, the only difference is that the values represent some CSS variables. |
The best way to see this is by example: | ||
|
||
{{"demo": "CssVarsProviderBasic.js", "iframe": true }} | ||
|
||
If you try to inspec the two `<code>` elements you will see that the style applied on them are different. The one using directly a theme token, looks something like this: | ||
|
||
``` | ||
<code style="color: rgb(25, 118, 210);">...</code> | ||
``` | ||
|
||
The one using the CSS variables however, allows developers to track the path of where the token is defined in theme: | ||
|
||
``` | ||
<code style="color: var(--md-palette-primary-main);">...</code> | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is hard to understand (I don't know what to look for when I first saw it). Maybe the markdown code is better than using demo.
|
||
### Customization | ||
|
||
At this moment, the `Button` component is the only component supporting CSS variables (the support is not requiring any breaking changes). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me wonder, should we release the doc + a guide (if the community wants to help make other components to support CSS variables) together?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we create an issue and link it here? We can add variables in one more component, that can serve as a template PR, similar as when we don the migration to emotion.
declare module '@mui/material/styles' { | ||
interface Theme { | ||
vars: Omit< | ||
MuiTheme, | ||
'typography' | 'mixins' | 'breakpoints' | 'direction' | 'transitions' | ||
>; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be more specific? for example, how to extend the palette.
I am closing this, will reopen a new one to point to master |