[Lens] Value in legend

[flash1293]

Fixes #95888

Adds a setting for showing value in the legend. It's shown for all xy charts

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[dej611]

Code LGTM. I would consider to add it also to partition charts.

When testing the feature I found some unexpected cases:

• When there's no date histogram by default there are no values

I understand the problem of "picking" the last entry in this configuration, but as is it's pretty confusing.

• There's a problem with empty buckets in date histogram:
  • if a category has been hit before, then the empty bucket becomes 0. This becomes even more strange when only some categories are shown as 0 while others don't

• if the empty bucket is at the left of the first data point in a date histogram then the "last bucket" value is shown - which is a bit confusing

[flash1293]

@dej611

I would consider to add it also to partition charts

I don't think it adds much value there. This is done mostly because it's a small step towards feature parity with TSVB.

The other things you noted are dictated by elastic-charts, so I think changing them is outside of the scope of this PR - I guess it would make sense to open an issue (or multiple issues) on the charts repo for this.

The question we have to answer is whether these things would stop us from exposing the functionality in Lens.
What do you think @ghudgins ?

[ghudgins]

@dej611's points are valid but, having now tried it, I don't think it's too bad. at least personally it's sort of how I expect these sorts of hover value features to work. @MichaelMarcialis might feel differently though.

I think this is worth shipping with those known areas of polish. We should make sure we create those follow-on issues while it's fresh. Regarding partition/proportion visualizations and this feature, to me this feature adds the most value to dense line graphs so it's okay to ship without.

This option decreases the amount of left/right legend label space and increases the need for more legend controls - #100231 & #41418 & elastic/elastic-charts#580

...but again, still worth it. It's adding more value than we had yesterday (so to speak)

[dej611]

@dej611's points are valid but, having now tried it, I don't think it's too bad. at least personally it's sort of how I expect these sorts of hover value features to work. @MichaelMarcialis might feel differently though.

I think the thing which confused me mostly was starting with an ordinal chart, and see nothing when I've enabled the feature - or better: there's a left "jump" of the legend label. So at first I thought it was broken - didn't realise it also worked "on hover" as there's already the popover for that.

Then I moved to date histogram and it was showing something (although some of the bugs above may affect also here), so I tried to hover the chart and saw the interactive value changing.

So, for ordinal charts, I see no particular value added compared to the current popover.

[flash1293]

@dej611 What are you suggesting?

[dej611]

I propose to remove it for ordinal charts, if you agree. Or alternatively to find some "default" value to show in this case. What do you think?

[flash1293]

@dej611 I wanted to avoid the extra complexity because it's such a minor thing, but I see what you are saying. Check out the latest version - the switch is only shown for non-ordinal charts.

[flash1293]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 078302b
• Storybooks Preview

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
lens	160	161	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
lens	1.3MB	1.3MB	+1.6KB

Unknown metric groups

API count

id	before	after	diff
lens	171	172	+1

History

• 💔 Build #129382 failed cf6a2ea
• 💚 Build #129238 succeeded d930d68
• 💚 Build #129100 succeeded 575075a

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kibanamachine]

💚 Backport successful

Status	Branch	Result
✅	7.x

This backport PR will be merged automatically after passing CI.

[MichaelMarcialis]

I appear to be joining the conversation a few hours late, but I still wanted to chime in. I think the value this PR adds still warrants the merging, but I also share some of the concerns that @dej611 raises above. Out of curiosity, have we considered the following?

When there's no date histogram by default there are no values

Can we show the total count of each legend item across the entire chart prior to hovering? That way, we have something to show for each legend item regardless if the chart is a date histogram and regardless if the user isn't hovering.

if the empty bucket is at the left of the first data point in a date histogram then the "last bucket" value is shown - which is a bit confusing

I personally find that having the default, not-hovering legend item count only include the last interval in the date histogram very confusing. From my perspective, I would imagine that when not hovering the chart, it would show an overall total count for each legend item (as described above). Only when hovering over the chart would it then scope the count to that particular hover area.

I'm not a data scientist however, so if these assumptions are incorrect, please feel free to contradict :)

[flash1293]

@MichaelMarcialis These things are fully controlled by elastic-charts and IMHO should be raised in a separate issue over there if we feel like we want to change this. I have some thoughts around it and think the current behavior makes sense though. Real quick (but IMHO any further discussion should happen in elastic-charts):

• Showing the last value is a time series thing - the last bucket is the most relevant for the current state of things
• I would imagine that when not hovering the chart, it would show an overall total count for each legend item - this might be a good idea for a chart using count of record as metric, but we have many other aggregations (even free style formula soon), and summing up all values of a series often doesn't make any sense. We might be able to only do this in certain cases, but then it's not obvious anymore what that value means just by looking at a chart. I don't think we should not try to be too clever here.