-
-
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] Allow setting a custom marker in legends and tooltips #16654
base: master
Are you sure you want to change the base?
[charts] Allow setting a custom marker in legends and tooltips #16654
Conversation
Deploy preview: https://deploy-preview-16654--material-ui-x.netlify.app/ Updated pages: |
993a4d0
to
e981343
Compare
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@alexfauquette @JCQuintas, a small question regarding API design. After I started working on adding custom shapes to scatter charts, I realized we'll probably want the scatter shape to match the legend/tooltip shape. |
111bfb4
to
0194616
Compare
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.
Very clean implementation, nice work.
Left a comment of something that is probably important in some use-cases
/** | ||
* ID of the series this mark refers to. | ||
*/ | ||
seriesId?: SeriesId; |
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.
Probably needs dataIndex
as well, since for PieCharts
the entries are based on that 😢
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.
Good point! I'll create a demo for pie charts, then 👍
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.
Glad I tried to create a demo. It turns out the API didn't allow for the same customization in pie charts as it did for others 😄
packages/x-charts/src/ChartsTooltip/ChartsItemTooltipContent.tsx
Outdated
Show resolved
Hide resolved
…in a separate PR.
40c3cf9
to
307ff39
Compare
Co-authored-by: Alexandre Fauquette <[email protected]> Signed-off-by: Bernardo Belchior <[email protected]>
/** | ||
* The data index of the pie item | ||
*/ | ||
dataIndex?: number; |
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.
Sorry, in this case the itemId
is already normalised to be id ?? dataIndex
😅
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.
Yeah, but I find that a bit weird. If the user receives a id ?? dataIndex
, how do they know if they should search for the ID or the data index? We don't enforce that all data points have an ID, so the user won't know whether to do data.find(d => d.id === itemId)
or data[itemId]
.
Now that I think of it, dataIndex
makes more sense because it's always present, while the ID is optional. In my opinion, we should always provide dataIndex
for those reasons, but we can consider also providing itemId
if you think it's useful.
What do you think?
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.
So replace itemId
with dataIndex
? I could agree with that. I think I just didn't think critically about this specific part when making the id
optional on pie items
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.
Yeah, either the ID should be mandatory or we should use dataIndex
. I'm not sure if the ID should be mandatory, though, so I guess dataIndex
is probably the best option. What do you think?
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.
We recently removed the requirement to have the id, it was required previously, so the correct way would be to use the dataIndex
here. It is a breaking change though
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'm not sure about the API.
Using the seriesId
(and/or dataIndex
) feels weird for real usecases. It forces users to take care of keeping in sync theirs slots and the data configuration.
From what I remember @JCQuintas The initial discussion was to allow either
Allowing to pass component like labelMark:
'line' | 'circle' | React.Elementto get
{data: ...., labelMark: }` and is such case we render the component. Easy, without having to take care of slotsProps.
The other with slots is to allow labelMark
extensions, and then it solves the pie chart issues by adding labelMark
in the pie items.
{ id: 0, data: [10], label: 'Series A' }, | ||
{ id: 1, data: [15], label: 'Series B' }, | ||
{ id: 2, data: [20], label: 'Series C' }, | ||
{ id: 3, data: [10], label: 'Series D' }, | ||
]; |
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.
{ id: 0, data: [10], label: 'Series A' }, | |
{ id: 1, data: [15], label: 'Series B' }, | |
{ id: 2, data: [20], label: 'Series C' }, | |
{ id: 3, data: [10], label: 'Series D' }, | |
]; | |
{ id: 0, data: [10, 15], label: 'Series A' }, | |
{ id: 1, data: [15, 20], label: 'Series B' }, | |
{ id: 2, data: [20, 25], label: 'Series C' }, | |
{ id: 3, data: [10, 15], label: 'Series D' }, | |
]; |
return ( | ||
<BarChart | ||
series={seriesConfig} | ||
xAxis={[{ scaleType: 'band', data: ['A'] }]} |
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.
For more advanced use cases, you can also provide a component to the `labelMark` slot to fully customize the mark. | ||
|
||
{{"demo": "LegendCustomLabelMark.js" }} | ||
|
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.
Maybe also adding a h4 title "Built-in shapes" in the previous section.
It's mostly to simplify to visual processing of information. Titles are useful to split text and demos in coherent bloks.
For example here without reading I can't guess to which demos the paragraph refers to
For more advanced use cases, you can also provide a component to the `labelMark` slot to fully customize the mark. | |
{{"demo": "LegendCustomLabelMark.js" }} | |
#### Custom shapes | |
For more advanced use cases, you can also provide a component to the `labelMark` slot to fully customize the mark. | |
{{"demo": "LegendCustomLabelMark.js" }} | |
Yeah, that's a good point. The reason I did this was for consistency with the other PR for custom shapes where I'm also using slots. Maybe I should move away from slots in that example as well?
Yeah, that API could work. The only downside I see is that if someone wants to use the same custom shape for all series, then they'd have to set the prop on every series, but I guess that's an acceptable trade-off.
Sorry, I didn't get this option. What do you mean by " |
My initial proposal for interface LabelMarkTypeExtension {}
// Series config ...
labelMarkType?: 'square' | 'circle' | 'line' | keyof LabelMarkTypeExtension
// Custom Legend/Tooltip/Slot
const Legend = ({labelMarkType}) => {
// decide what to do based on mark type.
} I think the current implementation of slots would still be necessary, so it is a step towards that. And I would leave the Providing Then on a future PR we implement the above, which would make the api more flexible from the series configuration side. This way you would have Accepting a |
Wy all the marks? The following would be still feasible. It only enforce on mark per series
|
So, what you're proposing is accepting a component in |
Related to #16640.
Allow setting a custom marker in legends and tooltips. This will be useful because scatter charts with custom shapes will probably want to have legends/tooltips with custom shapes.
Open questions:
Left heatmap out in this PR because its tooltip implementation it separate. Will implement it in a follow-up PR, along with documentation.