-
-
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 y-axis tick label overflow #16846
base: master
Are you sure you want to change the base?
[charts] fix y-axis tick label overflow #16846
Conversation
Deploy preview: https://deploy-preview-16846--material-ui-x.netlify.app/ |
CodSpeed Performance ReportMerging #16846 will not alter performanceComparing Summary
Benchmarks breakdown
|
@alexfauquette @JCQuintas should we consider once again updating the default axis size? Now for the y-axis 😛 The default axis size of 30px isn't enough to render "1,000" without ellipsis: To do so, we'd need a width of 42px: Should we increase the axis size? Would it make sense to reduce the margin or should we keep it as is? 🤔 |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
e7fa935
to
1819759
Compare
68a7125
to
0747a89
Compare
Increased it to 50px and solved the overflows of most demos. Let me know if you think that's acceptable |
That's probably for the better if it makes it so the defaults are better for everyone, I'll take a look at the screenshots |
It seems 40 would fit an entire 4 character number, though I suppose it doesn't because there are some margins expected to exist? |
To fit "1,000" we would need 42px as indicated in this comment. Without the comma, 40px might fit, yeah. Do you prefer if we chose 40px? It seems adding a comma is the default format. |
My brain didn't compute the comma 😅 I believe the best approach would be the lowest size we can have that solves most of the cases we have. Ofc my brain would prefer a round number, but If 42 is the lowest, then we might want to use that instead. |
Ok, but I'd increase a couple pixels to maybe 45px. Text rendering can be different across different OSes, so it's possible that the same font and same text have different sizes. |
e14bb2d
to
8872087
Compare
8872087
to
5b00547
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.
Nice port from x-axis to the y-axis 👍
Maybe a small message in the description of the PR to be sure we don't forget to mention it in the changelog
@@ -174,6 +247,15 @@ function ChartsYAxis(inProps: ChartsYAxisProps) { | |||
x: positionSign * (axisWidth - labelHeight), |
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 is not directly related to this PR, but I just noticed this x position could be replaced by
x: positionSign * (axisWidth - labelHeight), | |
x: positionSign * axisWidth, |
and the label placement could be modified with
- dominantBaseline: 'auto',
+ dominantBaseline: 'text-before-edge',
(or text-after-edge
I never remember who is who)
Such that the axis label does not depend on text measure anymore
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.
Updated 👍 it doesn't allow us to get rid of the label height measurement, 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.
it doesn't allow us to get rid of the label height measurement, though.
Not for the clean renderµ. But at least the axis main label should not move between the server-side rendering and the hydration since labelHeight
does not impact it anymore
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, good point 👍
dd289df
to
9367f14
Compare
if (isRtl) { | ||
[topBoundFactor, bottomBoundFactor] = [bottomBoundFactor, topBoundFactor]; | ||
} |
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.
if (isRtl) { | ||
[leftBoundFactor, rightBoundFactor] = [rightBoundFactor, leftBoundFactor]; | ||
} |
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.
Fixes RTL:
Screen.Recording.2025-03-24.at.12.25.02.mov
1dd7314
to
c69a00f
Compare
@@ -148,6 +149,10 @@ function shortenLabels( | |||
[leftBoundFactor, rightBoundFactor] = [rightBoundFactor, leftBoundFactor]; | |||
} | |||
|
|||
if (isRtl) { | |||
[leftBoundFactor, rightBoundFactor] = [rightBoundFactor, leftBoundFactor]; |
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 good to leave a small comment on this code to mention it is to prevent an intermediate assignment 😅
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.
From my point of view, it's clear what's happening, so I saw no need for a comment.
Nevertheless, I can add it, but this is used in 4 different places, should I leave the comment in all 4 places?
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.
Just add it to the first usage on each of the files
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.
Or you could extract the logic somehwere, they seem the same
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.
But this is a nitpick, can be done after
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'll do it later as a follow-up, then 👍
a29e07c
to
ebce504
Compare
Part of #10928.
Depends on:
Fixes tick label overflow for the y-axis. It follows the same approach as #16709, but the y-axis doesn't hide overlapping labels at the moment, which is why in the "after" image below you'll see that there's overlapping labels, namely when the labels are rotated -90 and 90 degrees.
The algorithm for hiding overlapping labels in the y-axis is out of scope for this PR.
Before:
After:

Changelog
Tick labels in the y-axis of cartesian charts will now have an ellipsis applied to prevent overflow.
If your tick labels are being clipped sooner than you would like, you can increase the y-axis size by increasing its width property.