New numeral field formatter

[timroes]

The numeral field formatter that currently exists in Kibana makes heavy use of numeral.js and the numeral.js format strings. Those are not very intuitive to users and we often see that there are several misunderstandings around then, e.g. that the period and comma inside the string do not actually represent whether you want to use a comma or period as thousand separator, but where it's placed. Also it only allows one locale to be used per Space, making it impossible to use different number locales on different index patterns or fields. The following comment has more issues listed.

Same as for currencies (#25993) we should create a new better numeral field formatter.
The numeral field formatter should allow you to select the following configuration parameters:

• Thousand separator character
• Decimal point character
• Amount of decimal digits shown
• Whether the sign should also be shown for positive numbers
• Suffix/Prefix appended to the number
• Whether Large numbers should be shortened (e.g. 3M, 3k, etc.)

We should have some common templates to preselect at least the first two in that list with e.g. US numberal format, or other common formats used.

Since the Numer.js library is pretty much dead right now (and we're already maintaining a separate fork), it would be good if we would try not to use it anymore.

Since the currency is just a prefix/suffix to the number, maybe we don't want to build the separate currency field formatter (#25993) but instead merge both into one.

[elasticmachine]

Pinging @elastic/kibana-app-arch

[kertal]

It will be hard to remove numer.js without breaking existing functionality. We could provide better defaults / templates, hiding numer.js behind the scene / still allowing it for advanced users.

We could take a look at http://numbrojs.com, which is a numeral.js fork

[kertal]

For the lovers of statistics: the numeral function is used 71 times in 28 files

[timroes]

@elastic/kibana-platform do you have any suggestion about or long term idea if and by what to replace numeraljs?

[anagfar]

Hi everyone!

I'd like to show port (TCP/UDP) numbers without commas, I've changed the format on my index to NUMERIC field and from default (0,0.[000]) to this: 00.[000].

But no changes whatsoever.. then try many other options.. none of them worked..

Do you know if some parameter must be allowed before it can work or what am I doing wrong?.

Thank you
Best regards

[anagfar]

By the way I'm using kibana 7.5 and the mapping I've try is integer and long

[wylieconlon]

We've been discussing this in the context of Lens, and I'd like to share my findings. #53535

The underlying formatting architecture (whether it's numeral.js or Intl.NumberFormat) does not need to be exposed to users, but we should probably start using Intl.NumberFormat because it gives users more control over number and currency formatting. It does not yet handle formatting of Bytes.

Switching to that API would let users choose:

• Display locale: more specific than language
• Currency unit
• Other units (temperature, distance, distance-per-time)
• Whether to use grouping or not
• Number of decimals, number of significant digits, etc
• Abbreviation of large numbers

These APIs seem supported in all browsers we target, so the main question is whether this is a breaking change, or if it can be done with backwards compatibility. I believe we can do this change in a backwards compatible way by keeping the existing numeral.js formatters where they are useful, and supplementing them with new formatters.

To propose a specific plan:

• Add a migration to index patterns which will look for any non-default numeral.js format strings, and move them all to a "Custom numeral.js" format for backwards compatibility.
• The exception to this is the Bytes formatter, but this formatter does not need a text input
• Create a "large number/abbreviated" formatter for thousands/millions/etc
• Create a currency formatter using Intl.NumberFormat. Users select currency type.
• Create a number formatter that exposes more options using dropdowns, such as number of decimals.
• Add a localization selector to both the index pattern and individual fields.

[wylieconlon]

There's another approach which might be a smaller migration path, previously described here: #8583

In summary, we could take ownership of the Numeral pattern language, and change the implementation. This could give us a way to maintain backwards compatibility while still adding features and fixing the localization issues.

[ppisljar]

@wylieconlon whats the current status and plan with this ?

[wylieconlon]

@ppisljar It hasn't changed much since I shared the update with your team. To break it down more, there were two paths:

• Continue using numeral, but with more ownership. This plan is described here, and needs your help to complete: Remove external dependency on Numeral.js #8583 (comment)
  a. @elastic/kibana-app-arch now owns field formatters and should take over maintenance.
  b. The way Kibana uses numeral is not like a standalone library. We should move it into kibana/packages.
  c. (done now) Because the way we use numeral is custom, we need to write Kibana documentation for formatting that we support. We should stop linking to 3rd-party docs. Create a docs site separate from the numeral-js docs numeral-js#16
  d. Backwards compatible pattern API, forward-facing API. This is how another Numeral fork did it, Numbro
• Implement new formatters using Intl.NumberFormat. This is blocked for many reasons until 8.0, and would need help from many teams.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[kertal]

We are closing this issue in order to provide better transparency of priorities. This issue won't be prioritized in the near future. We track it in #163011 for long term planning.