feat(xy): hide labels that protrude the bar geometry#1233
feat(xy): hide labels that protrude the bar geometry#1233markov00 merged 13 commits intoelastic:masterfrom
Conversation
There was a problem hiding this comment.
@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
hideClippedValueas:hideClippedValue?: boolean | { edges?: boolean, geometries?: boolean }The default
booleanvalue 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 elementflag, 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'
|
|
||
| const displayValue = | ||
| displayValueSettings && displayValueSettings.showValueLabel | ||
| const displayValue: BarGeometry['displayValue'] | undefined = |
There was a problem hiding this comment.
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.
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.
| height: textScalingFactor * fixedFontScale, | ||
| hideClippedValue, | ||
| isValueContainedInElement: displayValueSettings.isValueContainedInElement, | ||
| hideIfOverflowsChartEdges, |
There was a problem hiding this comment.
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
| const hideIfOverflows: Set<LabelOverflowConstraint> = new Set( | ||
| displayValueSettings?.hideIfOverflows ?? [ | ||
| LabelOverflowConstraint.ChartEdges, | ||
| LabelOverflowConstraint.BarGeometry, | ||
| ], | ||
| ); |
There was a problem hiding this comment.
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.
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.
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
monfera
left a comment
There was a problem hiding this comment.
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 |
nickofthyme
left a comment
There was a problem hiding this comment.
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
overflowConstraintsprop now replaces the existingBarSeries.displayValueSettings.hideClippedValueprop extending the existing feature with the ability to hide labels that protrude the bar geometry.BREAKING CHANGE: an API change is introduced:
hideClippedValueis removed in favour ofoverflowConstraints?: Array<LabelOverflowConstraint>;. The array can contain one or multiple overflow constraints identified inLabelOverflowConstraintDetails
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../srcexcept for test data & storybook)