-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
[charts] Fix charts not passing className to root element #13647
[charts] Fix charts not passing className to root element #13647
Conversation
Deploy preview: https://deploy-preview-13647--material-ui-x.netlify.app/ |
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.
Refs passed to ResponsiveChartContainer go to wrapper div instead of svg element. Breaking?
⚠️
Yes, this seems to be breaking change. Even if it's not the standard, their is some consistency by always passing the ref to the SVG component.
packages/x-charts-pro/src/ResponsiveChartContainerPro/ResponsiveChartContainerPro.tsx
Outdated
Show resolved
Hide resolved
I don't remember if we decided to do V8 or not 😅, should we wait to merge this?
I think if it is necessary to have it always on the SVG we could have a proper |
The v8 should be in 6 months
This would not fix the breaking change aspect. Someone using the
Is it the main reason to do the modification? |
I didn't mean it as a solution, but rather as a feature. If we want the user to always have access to the SVG directly, we can have a prop that does exactly that. Otherwise I think the My point of view is that if I have the topmost ref I can get any of the children elements I need, though I also see it being useful to have a ref directly to the SVG element. |
…arts-charts-dont-pass-classname-to-root-element
…arts-charts-dont-pass-classname-to-root-element
@alexfauquette reverted ref forwarding to forward to the SVG element. |
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.
👍
@@ -50,6 +50,8 @@ export const useBarChartProps = (props: BarChartProps) => { | |||
onHighlightChange, | |||
borderRadius, | |||
barLabel, | |||
className, | |||
...rest |
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 naming convention in the codebase?
...rest | |
...other |
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.
Added changes to #13844
import type { SeriesContextProviderProps } from '../context/SeriesContextProvider'; | ||
import type { ZAxisContextProviderProps } from '../context/ZAxisContextProvider'; | ||
import type { ChartContainerProps } from './ChartContainer'; | ||
|
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.
Usually, we don't use blank lines in imports:
@@ -0,0 +1,30 @@ | |||
import * as React from 'react'; | |||
import { createRenderer, describeConformance } from '@mui/internal-test-utils'; | |||
import { BarChart } from './BarChart'; |
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.
It's a public API, it should be:
import { BarChart } from './BarChart'; | |
import { BarChart } from '@mui/x-charts/BarChart'; |
to get a bit closer to an end-to-end test, and also make it clearer it's public.
x the other cases.
// MatchMedia is not fully supported in all environments, so we need to check if it exists before calling addEventListener | ||
mql.addEventListener?.('change', handleMediaChange); |
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.
Something doesn't make sense to me. If it's not fully supported in all environments, how is it possible for useMediaQuery()
to rely on:
// MatchMedia is not fully supported in all environments, so we need to check if it exists before calling addEventListener | |
mql.addEventListener?.('change', handleMediaChange); | |
mql.addEventListener('change', handleMediaChange); |
I conclude that one of the two is wrong (either in Core or in X)
Actually useColorScheme()
uses mql.addListener
, why not mql.addEventListener
.
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.
Both useMediaQuery.ts and useMediaQuery.test.js have ways of preventing the code from executing.
In the main code we seem to be testing for the presence of window.matchMedia
, which we do in our code as well, but our tests add a stub for it in stubMatchMedia
On the useMediaQuery.test.js
test themselves, it seems we use css-mediaquery
to completely override the matchMedia
behaviour implementing our own event emitter, which in turn never gets to the issue
Regarding using .addListener
vs .addEventListener
. .addListener
is deprecated. Typescript marks it as deprecated and so does MDN
'mergeClassName', 'propsSpread', 'reactTestRenderer', 'rootClass', 'refForwarding'
ResponsiveChartContainer
go tosvg
element.Gauge
andPieChart
componentsMediaQueryList
error on jsdomfixes #13292