-
Notifications
You must be signed in to change notification settings - Fork 120
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(bar_chart): add Alignment offset to value labels #784
Conversation
Make it possible to position value labels based on bar relative geometry
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've put a small comment on how to refactor the long list of switch/if
I'm ok with the approach and the proposed API for that
Compute offset distinctly per direction
Sync new labels alignment feature API with the doc
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.
Everything seems to work fine except for a 180 degree rotation where: the vertical alignment is not working well
Also please note that the debug
rectangle doesn't reflect the alignment: try to flag the debug
check on the label story and you will see the issue when changing the alignment.
One more thing to add:
it will be great to have VRTs for every situation: all rotation + all configuration of alignment.
Please take a look at integration/tests/interactions.test.ts
and a new set of tests for the various situations (you can run the VRTs for a specific file and/or a subset of tests with yarn test:integration:local your_test_file_name.test.ts --testNamePattern "your test name"
const CHART_ROTATION: Record<string, Rotation> = { | ||
BottomUp: 0, | ||
TopToBottom: 180, | ||
LeftToRight: 90, | ||
RightToLeft: -90, | ||
}; |
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 100% sure what are you referring to with these directions. All these terms resemble a mirror/flip action more than a rotation.
If you are using these to simplify the understanding of the rotation, please add a comment on the code where you are using them (like in each case
of the switch
few lines below
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 I don't think this is necessary, we could just make a comment on each of the switch cases below. Unless you are planning to expose this constant to the consumer for simplicity.
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.
Yes, the original idea was to export them as they may be more readable than numbers.
Not really in the scope of this PR, but they helped to code the solution giving some more semantic.
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 that's the case I think we should rename the enum from CHART_ROTATION
to something more descriptive.
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.
Tested locally and works great, just left a few comments.
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, adding some functional test will be great to avoid regressions:
please take a look at: integration/tests/interactions.test.ts
on how to create VRTs with different knob options
Codecov Report
@@ Coverage Diff @@
## master #784 +/- ##
==========================================
- Coverage 74.29% 71.90% -2.40%
==========================================
Files 270 337 +67
Lines 9274 11929 +2655
Branches 1991 2589 +598
==========================================
+ Hits 6890 8577 +1687
- Misses 2377 3327 +950
- Partials 7 25 +18
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
Works well!
# [24.0.0](v23.2.1...v24.0.0) (2020-10-19) ### Bug Fixes * **annotation:** annotation rendering with no yDomain or groupId ([#842](#842)) ([f173b49](f173b49)), closes [#438](#438) [#798](#798) ### Features * **bar_chart:** add Alignment offset to value labels ([#784](#784)) ([363aeb4](363aeb4)) * **bar_chart:** add shadow prop for value labels ([#785](#785)) ([9b29392](9b29392)) * **bar_chart:** scaled font size for value labels ([#789](#789)) ([3bdd1ee](3bdd1ee)), closes [#788](#788) * **heatmap:** allow fixed right margin ([#873](#873)) ([16cf73c](16cf73c)) ### BREAKING CHANGES * **bar_chart:** The `DisplayValueStyle` `fontSize` property can now express an upper and lower bound as size, used for the automatic scaling. * **bar_chart:** The `DisplayValueStyle` `fill` property can now express a border color and width, or let the library pick the best match based on contrast using the textInvertible parameter.
🎉 This PR is included in version 24.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
# [24.0.0](elastic/elastic-charts@v23.2.1...v24.0.0) (2020-10-19) ### Bug Fixes * **annotation:** annotation rendering with no yDomain or groupId ([opensearch-project#842](elastic/elastic-charts#842)) ([6bad0d7](elastic/elastic-charts@6bad0d7)), closes [opensearch-project#438](elastic/elastic-charts#438) [opensearch-project#798](elastic/elastic-charts#798) ### Features * **bar_chart:** add Alignment offset to value labels ([opensearch-project#784](elastic/elastic-charts#784)) ([106d924](elastic/elastic-charts@106d924)) * **bar_chart:** add shadow prop for value labels ([opensearch-project#785](elastic/elastic-charts#785)) ([de95b44](elastic/elastic-charts@de95b44)) * **bar_chart:** scaled font size for value labels ([opensearch-project#789](elastic/elastic-charts#789)) ([8b74a9d](elastic/elastic-charts@8b74a9d)), closes [opensearch-project#788](elastic/elastic-charts#788) * **heatmap:** allow fixed right margin ([opensearch-project#873](elastic/elastic-charts#873)) ([dd34574](elastic/elastic-charts@dd34574)) ### BREAKING CHANGES * **bar_chart:** The `DisplayValueStyle` `fontSize` property can now express an upper and lower bound as size, used for the automatic scaling. * **bar_chart:** The `DisplayValueStyle` `fill` property can now express a border color and width, or let the library pick the best match based on contrast using the textInvertible parameter.
Make it possible to position value labels based on bar relative geometry
Summary
This is a draft proposal for value label positioning within the bar chart with relative alignment.
There are still some open questions, such:
default
value be? Each chart rotation configuration has its own default alignment, so, for the moment, I've just extended theTextAlignment
in this scenario to handleundefined
valuesChecklist