[Lens] Allow palette configuration for metric

[dej611]

Summary

Fixes #102035

This PR introduces the palette configurator to the metric visualization in Lens.

By default 3 stops are computed starting from the current metric.

When the metric value is 0 then a special [-50, 100] range is used (in order to not collapse the color stop values AND have 0 in the middle of the current range).

It also works for negative values correctly:

Custom stops are respected and override the default computation above when they exists.

• Build a first version
• Check compatibility with [MetricVis] Expression metricVis API update.  #114116
• Check all i18n labels
• Write tests for the shared palette panel
• Write tests for the metric expression, dimension panel, visualization, functional
• Write migration no need, just fallback to none for old metrics
• Check with negative values
• Check with zero value
• Check for array values?
• Fix reverse bug

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)
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk	Probability	Severity	Mitigation/Notes
Multiple Spaces—unexpected behavior in non-default Kibana Space.	Low	High	Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces.
Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks.	High	Low	Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure.
Code should gracefully handle cases when feature X or plugin Y are disabled.	Medium	High	Unit tests will verify that any feature flag or plugin combination still results in our service operational.
See more potential risk examples

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[dej611]

@elasticmachine merge upstream

[dej611]

@elasticmachine merge upstream

[dej611]

@elasticmachine merge upstream

[dej611]

@elasticmachine merge upstream

[ghudgins]

I gave this PR a look (from the commit ~18 hours ago). here's my feedback:

• As long as we aren't on Michael's updated designs I think we need Color Continuity type control. Once we're on Michael's designs this will make more sense
• The palette preview isn't able to do the right thing (especially on 2 colors) because there's no known domain of the palette. maybe we should just do equal stops on the preview for these types of visualizations (thinking this & goal vis will have the same problem)?

[dej611]

Fixed the two raised issues @ghudgins .
Also now initial values are persisted, using the initial metric as reference.

[dej611]

@elasticmachine merge upstream

[dej611]

@elasticmachine merge upstream

[mbondyra]

  const rawValue = row[accessor];

  // NOTE: Cardinality and Sum never receives "null" as value, but always 0, even for empty dataset.
  // Mind falsy values here as 0!
  if (typeof rawValue !== 'number') {
    return getEmptyState();
  }

This would allow us to avoid type assertion, WDYT?

[mbondyra]

When the metric value === 1, the default values for the stops are nice and rounded:

but then the next added stop is not rounded - looks like you may refactor roundStopValues and use it for single value when adding a value.

[mbondyra]

1. Create the following metric visualization with on ecommerce data with timerange of 30 days:

2. For some reason, color is green:

3. Edit a second stop from 0 to -1 to 0
4. For some reason, the color switches to yellow:

Nov-16-2021.09-46-58.mp4

I think the initial value color for 0 might not be of a proper type (number instead of string) but not sure.

[mbondyra]

**EDIT, nevermind, missed Marco's comment about work on EUI there**

The palette preview isn't able to do the right thing (especially on 2 colors) because there's no known domain of the palette. maybe we should just do equal stops on the preview for these types of visualizations (thinking this & goal vis will have the same problem)?

I wonder if we should do the same also for custom palettes (always display equal stops)? For example, in 0-10-20, because of the current value 1, the last range (red color) looks very small.

For 0-1-2 it looks ok:

[dej611]

The palette preview isn't able to do the right thing (especially on 2 colors) because there's no known domain of the palette. maybe we should just do equal stops on the preview for these types of visualizations (thinking this & goal vis will have the same problem)?

I wonder if we should do the same also for custom palettes (always display equal stops)? For example, in 0-10-20, because of the current value 1, the last range (red color) looks very small.

From my understanding the uniform distribution should be always applied in #116422 . I hope most of the complex code here to disappear with the new UI and stops color structure.

[mbondyra]

Shouldn't we show a palette indicator in the dimension button? Not sure about that because there's just one color displayed at once so it's different than the pie or xy.
metric:

xy breakdown:

[dej611]

Shouldn't we show a palette indicator in the dimension button? Not sure about that because there's just one color displayed at once so it's different than the pie or xy.

That's a good point. I think it is not necessary in this case, but I see why it can still make sense. No strong opinion here. cc @ghudgins @flash1293 what do you think about it?

[flash1293]

In favor of showing the palette indicator to stay consistent - if a dimension is doing coloring, it should be shown in the UI

[dej611]

Addressed all issues reported here:

• Rounding problem:

When the metric value === 1, the default values for the stops are nice and rounded ... but then the next added stop is not rounded

Operating the fix on the shared area, this should also fix #117512

• Initial zero value

• Palette indicator on the dimension field

And all the other code review feedbacks 👍

[mbondyra]

Code LGTM, tested and all works good 👍🏼

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 6bfc0a9
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
lens	676	683	+7

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	237	239	+2

Async chunks

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

id	before	after	diff
lens	955.3KB	961.9KB	+6.6KB

Page load bundle

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

id	before	after	diff
lens	43.4KB	44.0KB	+662.0B

Unknown metric groups

API count

id	before	after	diff
lens	255	257	+2

History

• 💔 Build #7367 failed 61a7a46
• 💚 Build #6569 succeeded 2b8f202
• 💛 Build #5881 was flaky a7bc585
• 💚 Build #5716 succeeded 74b8295
• 💚 Build #5367 succeeded 389749b
• 💔 Build #5313 failed c262008

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

[smchamberlin]

@dej611 , is the code that was merged in for this only for metric? I would love to use this in my bar graph ... I see there is an issue already open for bar graph which references this merge, but seems it is still open: #4482
and I only see this in the UI under metric ...

Thanks!