Skip to content
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

Conversation

JCQuintas
Copy link
Member

@JCQuintas JCQuintas commented Jun 27, 2024

  • Fix conformance for all charts in 'mergeClassName', 'propsSpread', 'reactTestRenderer', 'rootClass', 'refForwarding'
  • Refs passed to ResponsiveChartContainer go to svg element.
  • Forward ref from Gauge and PieChart components
  • Prevent MediaQueryList error on jsdom

fixes #13292

@JCQuintas JCQuintas added bug 🐛 Something doesn't work component: charts This is the name of the generic UI component, not the React module! labels Jun 27, 2024
@JCQuintas JCQuintas self-assigned this Jun 27, 2024
@mui-bot
Copy link

mui-bot commented Jun 27, 2024

Deploy preview: https://deploy-preview-13647--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against f82dec6

@JCQuintas JCQuintas requested a review from alexfauquette July 2, 2024 18:19
Copy link
Member

@alexfauquette alexfauquette left a 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.

@JCQuintas
Copy link
Member Author

JCQuintas commented Jul 3, 2024

Yes, this seems to be breaking change.

I don't remember if we decided to do V8 or not 😅, should we wait to merge this?

Even if it's not the standard, their is some consistency by always passing the ref to the SVG component.

I think if it is necessary to have it always on the SVG we could have a proper svgRef that can be passed in? 🤔 Conformance tests don't properly work without the ref there 😅

@alexfauquette
Copy link
Member

I don't remember if we decided to do V8 or not 😅, should we wait to merge this?

The v8 should be in 6 months

I think if it is necessary to have it always on the SVG we could have a proper svgRef that can be passed in?

This would not fix the breaking change aspect. Someone using the ref to access the SVG will get access to a wrapping div after this modification

Conformance tests don't properly work without the ref there

Is it the main reason to do the modification?

@JCQuintas
Copy link
Member Author

This would not fix the breaking change aspect. Someone using the ref to access the SVG will get access to a wrapping div after this 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 ref should probably go to the topmost element. Though I don't know how we handle it in the main lib.

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.

@JCQuintas
Copy link
Member Author

JCQuintas commented Jul 10, 2024

@alexfauquette reverted ref forwarding to forward to the SVG element.

@JCQuintas JCQuintas requested a review from alexfauquette July 11, 2024 08:23
Copy link
Member

@alexfauquette alexfauquette left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@JCQuintas JCQuintas merged commit 55aee56 into mui:master Jul 11, 2024
17 checks passed
@JCQuintas JCQuintas deleted the 13292-charts-charts-dont-pass-classname-to-root-element branch July 11, 2024 14:13
@@ -50,6 +50,8 @@ export const useBarChartProps = (props: BarChartProps) => {
onHighlightChange,
borderRadius,
barLabel,
className,
...rest
Copy link
Member

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?

Suggested change
...rest
...other

Copy link
Member Author

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';

Copy link
Member

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:

Suggested change

@@ -0,0 +1,30 @@
import * as React from 'react';
import { createRenderer, describeConformance } from '@mui/internal-test-utils';
import { BarChart } from './BarChart';
Copy link
Member

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:

Suggested change
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.

Comment on lines +32 to +33
// MatchMedia is not fully supported in all environments, so we need to check if it exists before calling addEventListener
mql.addEventListener?.('change', handleMediaChange);
Copy link
Member

@oliviertassinari oliviertassinari Jul 15, 2024

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:

Suggested change
// 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.

Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something doesn't work component: charts This is the name of the generic UI component, not the React module!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[charts] Charts don't pass className to root element
4 participants