[test] Fix broken master branch #35446
Conversation
oliviertassinari
force-pushed
the
fix-flaky-test
branch
from
7e109e8
to
bd62693
Compare
|
packages/mui-joy/src/Box/Box.test.js
Outdated
| expect(theme.unstable_sx({ bgcolor: 'primary.500' })).to.deep.equal({ | ||
| // TODO fixme | ||
| // backgroundColor: 'var(--joy-palette-primary-500)', | ||
| backgroundColor: 'primary.500', |
There was a problem hiding this comment.
This probably fails because it is not used inside CssVarsProvider. The CssVarsProvider is required when using @mui/joy: https://mui.com/joy-ui/getting-started/usage/#quickstart. cc @siriwatknp is this correct?
There was a problem hiding this comment.
yes, you are correct.
The theme output from extendTheme() does not have theme.vars and theme.palette.* yet. That's why theme.unstable_sx returns primary.500 because it could not find the palette.
Using ThemeProvider should be enough because it attaches vars and use light color scheme as a palette.
There was a problem hiding this comment.
All other tests already use the CssVarsProvider, I'd suggest adding it to this test too.
There was a problem hiding this comment.
I push a change, I moved these tests to extendTheme, as it looked more related to it. I also wrap the tests with CssVarsProvider and the results look as expected now.
There was a problem hiding this comment.
Ahhh. I have been confused about this a couple of times. Sometimes .vars was defined sometimes not. I couldn't really pinpoint what was happening. Now I get it, it's about either accessing the theme with the context or accessing the theme with a direct import.
Why is CssVarsProvider mutating the theme to add the vars? I mean, why is this logic not inside extendTheme? Looking at the code, It seems that we could move this logic up in the chain.
There was a problem hiding this comment.
I would expect that the theme would add vars and maybe point them to the plain values before the CssVarsProvider is used. This would be safest. The palette could be generated the same way too. I know we have it for defaultTheme, maybe we can just add this logic to extendTheme too. I was thinking about this when creating the theme for Material You, but for now used the same approach in Joy UI.
There was a problem hiding this comment.
In the code:
material-ui/packages/mui-system/src/cssVars/createCssVarsProvider.js
Lines 154 to 158 in 33a0e1c
It seems that theme.vars is defined with params that aren't specific to the theme provider. This is what put me on the track of, we should be able to do:
export const theme = extendTheme({ /* … */ });import theme from './myTheme';
{
color: theme.vars.palette.primary.main,
},Pretty much like https://vanilla-extract.style/documentation/api/create-theme/.
for now used the same approach in Joy UI
👍 to keep these in sync
There was a problem hiding this comment.
I will draft a PR for this to see what the changes would look like.
|
The patch looks great, @mnajdova thanks for the fix |
Something I noticed while I was working on the KPI page. master is broken:
https://www.notion.so/mui-org/KPIs-1ce9658b85ce4628a2a2ed2ae74ff69c#59bb101e5eab4375a6018d6694d036a7
The issue is that since #35150, this test never pass:
https://app.circleci.com/pipelines/github/mui/material-ui/87228/workflows/4504c13e-6d89-49fe-9589-60586b34e23a/jobs/461431
My proposed solution is to remove it.
I was also curious, I saw we had no tests for
theme.unstable_sxso I added one. On my end, it doesn't behave exactly like I was exepecting:createTheme()I would expect it returns the raw value.extendTheme()I would expect it returns the CSS variable.I even wonder if we shouldn't rename these helpers for clarity:
createTheme->createRawTheme. It's the plain valuesextendTheme->createTheme. It's the new oneLive demo https://codesandbox.io/s/red-meadow-eejvie?file=/demo.tsx.