[Lens] Pie and donuts should have a size ratio setting#120101
[Lens] Pie and donuts should have a size ratio setting#120101DianaDerevyankina merged 27 commits intoelastic:mainfrom
Conversation
# Conflicts: # x-pack/plugins/lens/public/pie_visualization/constants.ts # x-pack/plugins/lens/public/pie_visualization/partition_charts_meta.ts # x-pack/plugins/lens/public/pie_visualization/to_expression.ts # x-pack/plugins/lens/public/pie_visualization/toolbar.tsx
| ({ value }) => value === stateParams.donutInnerAreaSize | ||
| )?.id || 'donutInnerAreaSizeOption-medium' | ||
| } | ||
| onChange={(sizeId) => { |
| idSelected={ | ||
| donutInnerAreaSizeOptions.find( | ||
| ({ value }) => value === stateParams.donutInnerAreaSize | ||
| )?.id || 'donutInnerAreaSizeOption-medium' |
There was a problem hiding this comment.
nit: with ? we normally use ?? instead of ||
| value: SharedPieLayerState['numberDisplay']; | ||
| inputDisplay: string; | ||
| }>; | ||
| donutInnerAreaSizeOptions: Array<{ |
There was a problem hiding this comment.
metadata should keep a generic data. let's exclude everything with a special chart name
| value: SharedPieLayerState['numberDisplay']; | ||
| inputDisplay: string; | ||
| }>; | ||
| innerAreaSizeOptions: Array<{ |
| legendPosition, | ||
| nestedLegend, | ||
| percentDecimals, | ||
| donutInnerAreaSize, |
There was a problem hiding this comment.
I don't understand why you use donutInnerAreaSize name instead of generic emptySizeRatio?
|
Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors) |
# Conflicts: # x-pack/plugins/lens/public/pie_visualization/to_expression.ts # x-pack/plugins/lens/public/pie_visualization/toolbar.tsx
stratoula
left a comment
There was a problem hiding this comment.
@dziyanadzeraviankina this looks great. Let's add some unit tests as the options appear under specific condtions.
@ghudgins @MichaelMarcialis can you also take a look and let us know if the selected ratios seem fine?
| value={stateParams.isDonut} | ||
| setValue={setValue} | ||
| /> | ||
| {props.showElasticChartsOptions && stateParams.isDonut && ( |
There was a problem hiding this comment.
Can you cover this functionality in the pie.test? I have other cases there, let's test that it is hidden when vislib is on or if it is a pie.
Also can we also add a test for lens to test that the visual options menu is only visible when we have a donut partition chart and not a pie or treemap etc
To my eyes, the ratio for the size differences between small-to-medium and medium-to-large appear to be quite large. For example, moving from small-top-medium appears as a small increase in the donut hole size, whereas going from medium-to-large appears as a very large increase in donut hole size. Would it be possible to distribute these sizes more evenly? Or is there a specific reason for this? CCing @gvnmagni in case he has additional thoughts. Also, as a small side thought, would |
|
agreed at the options feeling a bit off. The large looks good but small & medium look both pretty small. I think the reasoning for this was to provide more space for the interior label but it's hard to imagine anyone who edits this setting changing to small (from medium) since they're so similar. |
|
@MichaelMarcialis @ghudgins I agree with your point. If we give only two options? (Large which will give the same ratio as vislib pie) and Normal (which will be what we have so far?) We can change the naming of course but maybe the small hole doesn't make any difference. |
|
Thank you @MichaelMarcialis for tagging me! I'm not aware of any specific rule about this ratio (a part avoiding holes too big or too small), I'd say that we should follow our common sense. I'd distribute these 3 ratio in order to have the distance between them consistent @monfera any thought about this? Any rule/practice that I'm not aware of? |
Consistent in terms of radius or area of the hole? I think the later would make more sense here. |
Agree! Even if in this case we are not encoding data with the area I'd say that we should always consider the area when dealing with these kind of chart. Thank you for mentioning this, I gave it for granted :) |
|
@elasticmachine merge upstream |
flash1293
left a comment
There was a problem hiding this comment.
So I don't have a strong opinion, but what about 0.3, 0.54 and 0.7 (defaulting to 0.3)?



This will make the change in area consistent giving the user options without changing our current default donut.
0.3has an area of 0.282743338820.54has an area of 0.916088417780.7has an area of 1.53938040026
Otherwise this PR looks good to me (agree with Stratoulas comments), we can also merge it without a final answer to the question on the hole ratios as it's easy to change afterwards
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
* [WIP][Lens] Waffle visualization type Closes: elastic#107059 * add showExtraLegend for waffle * add tests * resolved 1 and 5 * resolved 6 * add sortPredicate for waffle chart type * [Lens] Pie and donuts should have a size ratio setting * Add a missed condition * Fix changing size for smallSlices * Add donut inner area size setting to pie visualization and update it for lens * Update test and rename some constants * Rename the setting * Move handler to a separate useCallback function * Update size ratios and add condition for legacy charts * Fix merge conflict issue * Change constants order * Add a couple of tests to check if the setting is displayed * Update ratio sizes Co-authored-by: Alexey Antonov <alexwizp@gmail.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes #65538
Summary
Added a setting for classic Pie and Lens Donut visualizations that allow to configure the donut thickness. Previous ratio is now "Small" and selected by default.
setting is hidden for

visualization:visualize:legacyPieChartsLibraryChecklist
Delete any items that are not applicable to this PR.
For maintainers