-
Notifications
You must be signed in to change notification settings - Fork 122
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
feat(xy): hide labels that protrude the bar geometry #1233
feat(xy): hide labels that protrude the bar geometry #1233
Conversation
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.
@dej611 Thanks for the review
- the new API prop is not super nice.
- The previous one was singular (
*ClippingValue
) while this has plural name*ClippingValues
.- It's a long name but at the same time it has shortenings in it (
*Geom*
). I would rather have a full name >hideGeometryClippedValue
.- As alternative I would consider also adding an object value to the
hideClippedValue
as:hideClippedValue?: boolean | { edges?: boolean, geometries?: boolean }The default
boolean
value should be converted to{ edges?: boolean }
internally
I've discussed and agree with @monfera to use a slight cleaner approach here 97fd23b
the hideClippedValue
and hideGeomClippedValues
are replaced by:
const LabelOverflowConstraint = Object.freeze({
BarGeometry: 'barGeometry' as const,
ChartEdges: 'chartEdges' as const,
});
...
hideIfOverflows?: Array<LabelOverflowConstraint>;
This allows us and the users to: combine easily the constraints. The API is also scalable and can accommodate other constraints along the way.
- I find a bit confusing the way this flag works combined with the
contain value label within bar element
- I get that probably they won't get combined that often, but while playing in the storybook example I found that enabling >both leads to something I would not expect.
- If there's a plan to remove the
contain value label within bar element
flag, it does not matter probably
You are right, I've deprecated the API prop and we will remove it soon.
Also, can you add the same flag to the advanced value labels example?
BREAKING CHANGE: the 'hideIfOverflows' option now replace 'hideClippedValues'
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.
// Based on rotation scale the width of the text box | ||
const bboxWidthFactor = isHorizontalRotation ? textScalingFactor : 1; | ||
|
||
const displayValue = | ||
displayValueSettings && displayValueSettings.showValueLabel | ||
const displayValue: BarGeometry['displayValue'] | undefined = |
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.
Does it need to also be undefined
, or could it just be an empty string? There are then many ways to not render an empty string, eg. just render it (nothing will show up) or test for text lengt === 0 or test for text truthiness (""
is falsey)
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.
this object has multiple properties, is not just the text string. IMHO I don't see how this can be better than having or not having an object.
? { | ||
fontScale: textScalingFactor, | ||
fontSize: fixedFontScale, | ||
text: displayValueText, | ||
width: bboxWidthFactor * displayValueWidth, | ||
height: textScalingFactor * fixedFontScale, | ||
hideClippedValue, | ||
isValueContainedInElement: displayValueSettings.isValueContainedInElement, | ||
hideIfOverflowsChartEdges, |
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.
Let's suppose, there's yet another constraint, would it need a new parameter here? If it's likely, maybe it's easier to pass around the Set, and check for has
at the place of application
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.
fixed in 5f0b2ee
const hideIfOverflows: Set<LabelOverflowConstraint> = new Set( | ||
displayValueSettings?.hideIfOverflows ?? [ | ||
LabelOverflowConstraint.ChartEdges, | ||
LabelOverflowConstraint.BarGeometry, | ||
], | ||
); |
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.
Still pondering: the users of the library are not end users but coders, so a Set<LabelOverflowConstraint>
might be a clearer API receptacle as the input is a set, rather than a bag (=multiset ie. possible duplicates) or array (ordered multiset). At the expense of trivial verbosity. From your earlier example:
overflowConstraints={['barGeometry', 'chartEdges']}
overflowConstraints={new Set(['barGeometry', 'chartEdges'])}
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.
As a consumer of the API I think the Set
is an implementation detail that should not be exposed. Unless there's another API usage of the Set
container I see no reason to expose it.
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 agree with @dej611 here, adding a Set
doesn't prevent the user adding duplicates in the array overflowConstraints={new Set(['barGeometry', 'chartEdges','barGeometry'])}
The cardinality is relatively low that it's easy to spot that manually. Internally we just get rid of duplicates
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.
LGTM, the comments are just for consideration, some of them fitting in the old theme of trying to avoid/remove union types esp. where the non-nil type can accomodate a sensible "nil" value eg. NaN for numbers or ''
for strings
Yes, you are right |
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 changes LGTM!
# [33.0.0](v32.0.0...v33.0.0) (2021-07-14) ### Features * **xy:** add null bars to geometry indexing ([#1226](#1226)) ([20b81a9](20b81a9)), closes [#950](#950) * **xy:** hide labels that protrude the bar geometry ([#1233](#1233)) ([be1fb3d](be1fb3d)), closes [#1234](#1234) ### BREAKING CHANGES * **xy:** an API change is introduced: `hideClippedValue` is removed in favor of `overflowConstraints?: Array<LabelOverflowConstraint>;`. The array can contain one or multiple overflow constraints enumerated as `LabelOverflowConstraint`
🎉 This PR is included in version 33.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Summary
The
overflowConstraints
prop now replaces the existingBarSeries.displayValueSettings.hideClippedValue
prop extending the existing feature with the ability to hide labels that protrude the bar geometry.BREAKING CHANGE: an API change is introduced:
hideClippedValue
is removed in favour ofoverflowConstraints?: Array<LabelOverflowConstraint>;
. The array can contain one or multiple overflow constraints identified inLabelOverflowConstraint
Details
I've added a different prop because both visibility filters are valid and useful.
Issues
fix #1234
Checklist
packages/charts/src/index.ts
(and stories only import from../src
except for test data & storybook)