[Lens] Introduce new duration formatter

[dej611]

Summary

Fixes #153378

This PR introduces a new Duration formatter, similar to the TSVB one and more complete like the Field Formatter one.

Few keys features of the new formatter:

• supports from and to unit selection
• supports Humanize (approximate) and Humanize (precise) outputs
• supports units below milliseconds
• supports decimals precision (with the exception of the humanize approximate output)
• supports suffix
• supports the compact version (with the exception of the humanize approximate output)

Input and Output options are now exported directly from the Field Formatter to have a shared list of options.

A first look at the new formatter in action: when enabled it the first time it will lands on Seconds => Humanize (Approximate) configuration (this emulates the current Field Formatter behaviour)

In this example the input was in Minutes so it is possible to change it from the default Seconds entry:

Switching output type to something else than Humanize (approximate) will make available both decimals and compact controls as well.
Custom suffix is supported as well.

When Decimals and Compact controls are disabled a helpful tooltip is shown to the user to explain why:

I've also prepared an alternate UI version which is more compact, using the DelimitedControls UI, but it does not looks that great. Maybe some design iteration could help make it better? cc @MichaelMarcialis

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

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[mbondyra]

Code LGTM, tested on Chrome 👌🏼

[davismcphee]

Code only review, field format changes LGTM 👍

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 4769b4c

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
fieldFormats	63	64	+1
lens	1110	1111	+1
total			+2

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
fieldFormats	249	253	+4

Async chunks

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

id	before	after	diff
expressionMetricVis	4.5KB	4.6KB	+66.0B
lens	1.4MB	1.4MB	+3.3KB
total			+3.4KB

Page load bundle

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

id	before	after	diff
fieldFormats	63.0KB	63.2KB	+252.0B
lens	36.2KB	36.3KB	+70.0B
total			+322.0B

Unknown metric groups

API count

id	before	after	diff
fieldFormats	288	292	+4

History

• 💔 Build #143956 failed c84b744
• 💚 Build #143820 succeeded c8615ae
• 💔 Build #143784 failed 67f38b6
• 💚 Build #143603 succeeded c85265c
• 💚 Build #143578 succeeded ec4c4b4

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

[MichaelMarcialis]

I've also prepared an alternate UI version which is more compact, using the DelimitedControls UI, but it does not looks that great. Maybe some design iteration could help make it better? cc @MichaelMarcialis

@dej611: Apologies for the delayed response. Leaving my feedback now, in case there is an opportunity for a follow-up PR.

I like the thinking behind using the EUI delimited controls, but I don't think the current layout affords us enough horizontal space for it to be used without needing to resort to abbreviations (see my example below).

As such, I think the direction you ultimately appear to have implemented makes the most sense (at least until some point in the future where we re-evaluate how form elements are laid out in the Lens configuration flyouts). However, I would make the following suggestions:

• Change the current "From" prepend label to "Convert" to make it clearer to users what is being asked of them.
• Hide the "Decimals" and "Compact actions" for elements when "Human-readable (approximate)" is selected (rather than disabling them). Doing so will be more consistent with how we handle conditional form elements across Lens.
• Change references of "Human-readable" to "Friendly". It is both shorter and possibly more accurate (since I imagine all available options are technically human-readable).
• Shrink the "Compact values" font size to 12px (xs size via EuiText component) to be consistent with other subordinate switch labels used in Lens flyouts.
• Apply a consistent minimum width to all prepended labels equal to the width of the largest label in the group (70px in the below example).

Regarding the "Human-readable" options, why the choice between approximate and precise? Are the two options necessary? Or can there not be a single "Human-readable" option?

Finally, I noticed that some of my previous suggestions as part of the "Custom format" selection are not as intended. I'm not sure if this is a regression, but noting my suggestions here again in the hopes that we can squeeze them in as well.

• Remove the conditionally appearing help text that appears below the "Value format" selector when "Custom format" is selected.
• Change the "Format" row to be compressed.
• Add new "Numeral formatting syntax" link as help text under the "Format" input.

CCing @amyjtechwriter, in case she has any additional input on some of the suggested wording.

[stratoula]

Thanx @MichaelMarcialis, I will create an issue for your feedback, we need to also alloq TSVB with duration formatter to be moved to Lens so we will have a follow up PR for sure