[Lens] add new metric visualization

[drewdaemon]

Summary

Resolve #134242

This adds the new metric visualization.

Screenshots

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

[MichaelMarcialis]

Here is my take on how to split it. Let me know if you disagree.

The split that you and @flash1293 have established sounds good to me.

The min and max in this case are negative infinity and infinity. I think it makes sense to discuss forcing custom min/max for all metric-type visualizations as an enhancement in 8.5.

Ah, yes. I'm recalling that now. During these 8.5 discussions, I'd love to also discuss changing the min/max input placeholders and button icons to infinity symbols in those cases where we're using infinity instead of the min/max data set values (just so it's crystal clear to our users).

[flash1293]

@mbondyra Colors should be fixed

[mbondyra]

nit: moving id to outside scope of the component makes the id more stable, otherwise the id gets changed with every rerender - I didn't notice any behaviour it would impact, but it's probably not a good practice, especially because the name stays the same:

id.mov

[drewdaemon]

Can definitely move the ID up the scope, but it seems like the name staying the same is an EUI bug?

[MichaelMarcialis]

Thanks for making the majority of those requested changes to quickly, @andrewctate! Amazing work! Acknowledging that we're pushing some comments/disucssions off to 8.5, this is looking good from my perspective. Adding a few last minute thoughts below, but approving now so I don't hold you up further. Thanks again for all your hard work on this!

• Within the "Metric" layer panel, the "Primary metric" dimension correctly shows a color palette preview when "Dynamic" color is selected. However, if "Static" color is selected, a color swatch preview does not appear to indicate the applied color for that dimension. Would it be possible to add one similar to how we do with other visualizations?

• Currently, the default "Primary metric" color of white (#ffffff) is being represented by a transparent swatch in the color picker, rather than a white swatch. Would it be possible to fix this?

• I know that @gvnmagni requested that we use white as the default background color for visualizations with only the "Primary metric" dimension populated. I understand the desire to do so in order to present ultimate neutrality and a blank slate for the users to build/customize upon. Currently however, I don't think we're in a good position to do so. I worry that users seeing the workspace as shown in the screenshot below might give the false impression that something is broken or wrong with their configuration. I know we're currently starting to have conversations around whether we should resize the workspace panel to conform to the visualization and/or whether we should provide perimeter borders for visualizations such as this, but I don't think the outcome of those discussions are planned to be added for 8.4. As such, I'm wondering if it makes better sense to restore the previous light gray default background color for visualizations with only the "Primary metric" dimension populated, just so it's clear to the user that nothing is broken. Thoughts?

• Do ya'll think we should change the "Progress bar direction" label to read "Bar direction" instead? Semantically, I view this element as more of a bar chart than a progress bar. This change would also help prevent the label from breaking a line.

• Do ya'll have any thoughts on changing the "Max columns" label to something like "Layout columns"? I'm wondering if this change helps to make it clearer as to what this setting does.

[mbondyra]

I didn't find anything that should block this anymore and the other issues we agreed to push. Approved! 🥳

[mbondyra]

same here as the comment below - maybe we can move it up the scope?

[gvnmagni]

• I know that @gvnmagni requested that we use white as the default background color for visualizations with only the "Primary metric" dimension populated. I understand the desire to do so in order to present ultimate neutrality and a blank slate for the users to build/customize upon. Currently however, I don't think we're in a good position to do so. I worry that users seeing the workspace as shown in the screenshot below might give the false impression that something is broken or wrong with their configuration. I know we're currently starting to have conversations around whether we should resize the workspace panel to conform to the visualization and/or whether we should provide perimeter borders for visualizations such as this, but I don't think the outcome of those discussions are planned to be added for 8.4. As such, I'm wondering if it makes better sense to restore the previous light gray default background color for visualizations with only the "Primary metric" dimension populated, just so it's clear to the user that nothing is broken. Thoughts?

Fine by me! 👍

[drewdaemon]

@MichaelMarcialis thank you! And thanks to @flash1293 and the team for pitching in to get this over the line.

Within the "Metric" layer panel, the "Primary metric" dimension correctly shows a color palette preview when "Dynamic" color is selected. However, if "Static" color is selected, a color swatch preview does not appear to indicate the applied color for that dimension. Would it be possible to add one similar to how we do with other visualizations?

Makes sense. Adding as a follow-up.

Currently, the default "Primary metric" color of white (#ffffff) is being represented by a transparent swatch in the color picker, rather than a white swatch. Would it be possible to fix this?

We changed it to "Auto." Does that solve it?

I'm wondering if it makes better sense to restore the previous light gray default background color for visualizations with only the "Primary metric" dimension populated, just so it's clear to the user that nothing is broken

Done!

change the "Progress bar direction" label to read "Bar direction"

Done!

changing the "Max columns" label to something like "Layout columns"

Done!

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: f68760f
• Storybooks Preview

Failed CI Steps

• FTR Configs #39
• FTR Configs #44

Test Failures

• [job] [logs] FTR Configs #39 / machine learning - data visualizer data view management "before each" hook for "sets custom label for existing field"
• [job] [logs] FTR Configs #44 / ObservabilityApp Observability Rule Details page Page components maps correctly the rule type with the human readable rule type

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
embeddable	79	81	+2
expressionMetricVis	22	60	+38
lens	935	943	+8
total			+48

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
expressionMetricVis	47	56	+9
lens	525	527	+2
total			+11

Async chunks

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

id	before	after	diff
expressionMetricVis	3.7KB	71.0KB	+67.3KB
lens	1.2MB	1.2MB	+14.8KB
total			+82.2KB

Canvas Sharable Runtime

The Canvas "shareable runtime" is an bundle produced to enable running Canvas workpads outside of Kibana. This bundle is included in third-party webpages that embed canvas and therefor should be as slim as possible.

id	before	after	diff
module count	4937	4939	+2

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
embeddable	3	4	+1
lens	40	41	+1
total			+2

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
embeddable	68.5KB	68.6KB	+123.0B
expressionMetricVis	8.9KB	10.0KB	+1.0KB
lens	34.0KB	34.3KB	+310.0B
total			+1.4KB

Unknown metric groups

API count

id	before	after	diff
embeddable	505	507	+2
expressionMetricVis	47	56	+9
lens	604	608	+4
total			+15

async chunk count

id	before	after	diff
expressionMetricVis	1	2	+1

ESLint disabled in files

id	before	after	diff
lens	2	3	+1

ESLint disabled line counts

id	before	after	diff
expressionMetricVis	2	1	-1

Total ESLint disabled count

id	before	after	diff
expressionMetricVis	2	1	-1
lens	29	30	+1
total			-0

History

• 💔 Build #60878 failed 75c4632
• 💔 Build #60814 failed 8364eb0
• 💔 Build #60734 failed f681381
• 💚 Build #60713 succeeded 9330a02
• 💔 Build #60674 failed b43e3e9

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