[Lens] Add suffix formatter

[flash1293]

Fixes #88402

This PR adds a simple way to add a suffix to a formatter:

• "Suffix" input is shown for all non-default formatters
• Can also be applied if time scaling is active (will nest to suffixes, one for the time unit, one for the user supplied string)
• Extended the existing suffix formatter with an option to provide a string

Open question: It's a little weird to mix it with percentage or bytes formatter - should it only be shown for the "number" formatter?

[elasticmachine]

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

[drewdaemon]

Open question: It's a little weird to mix it with percentage or bytes formatter - should it only be shown for the "number" formatter?

I was trying to think of a use-case for percent/bytes. This one is sort-of viable(?)

[drewdaemon]

Tested and it works great. Only thing I didn't test is the following bullet (because I don't know how 😅 )

Can also be applied if time scaling is active (will nest to suffixes, one for the time unit, one for the user supplied string)

[drewdaemon]

Do I understand correctly that this interface defines configuration to format values for display to the user?

If so, we could consider calling it DisplayFormatConfig or something. I'm not sure what we gain by prepending Lens since we're already in the lens plugin.

[drewdaemon]

Maybe ValueFormatConfig?

[flash1293]

I like it!

[mbondyra]

It's a little weird to mix it with percentage or bytes formatter - should it only be shown for the "number" formatter?

Yeah, it feels weird for me. But I also find weird that we put formatter in between the number and time scaling unit.. I don't have a good solution with a suffix. I think it still can be useful for the user, and maybe in the future we'll solve this issue with template instead.

[mbondyra]

Tested it and it works as expected in Chrome. However, I am just wondering from the product side how are we going to expand on this issue - are we planning on adding prefix too, or template formatting similar to TSVB? Do we accept the limitations that come with this solution? (and the weird behavior for time scaling too?)
If at some point we would be planning on replacing it with template, maybe it makes sense to prepare saved object shape for it by replacing the part

"format": {
    "id": "number",
    "params": {
        "decimals": 0,
        "suffix": "$"
    }
}

to:

"format": {
    "id": "number",
    "params": {
        "decimals": 0,
        "template": "{{value}}$"
    }
}

and parse the template to get the suffix? Just a thought though, maybe I am overthinking it.
If the product is ok with this solution, I am too :)

[flash1293]

We are definitely in need of a larger scope refactoring of how formatting works in general today in Kibana overall. There have been some early discussions, but it's not planned for the medium term - this PR (just allowing the suffix) is meant as a stopgap measure to solve a certain common use case now until we can revisit the larger issue. We can wait until @ghudgins gets back before merging to make sure this is the direction we want to take now.

[flash1293]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 5e984b2
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

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.1MB	1.1MB	+785.0B

Page load bundle

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

id	before	after	diff
lens	45.4KB	45.5KB	+34.0B

History

• 💚 Build #33374 succeeded 8be4d37
• 💔 Build #33108 failed e4ca06a
• 💚 Build #32560 succeeded 32928a0

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

[ghudgins]

++ similar to everyone else I agree that it's a bit weird but I do think it's better to be predictable--I would hate for a user who is using % to not be able to find this setting. I think it's good to go as is