[Lens] Applying bytes formatter to tick labels shows wrongly rounded ticks #92152
Labels
bug
Fixes for quality problems that affect the customer experience
Feature:Lens
Team:Visualizations
Visualization editors, elastic-charts and infrastructure
Kibana version:
7.12
Browser version:
Chrome
Browser OS version:
MacOS
Original install method (e.g. download page, yum, from source, etc.):
cloud
Describe the bug:
When changing the
value format
toBytes
, the format is applied to the chart at the last stage of the rendering through thetickFormat
props in the Elastic-Chart axis. As seen on the screenshot, applying the byte formatter on the "output" of the chart computation causes the axis tick round feature to not work properly, creating an irregular represented scale.It can get even worst when reducing the decimal fraction to 0.
Steps to reproduce:
Value format
to BytesExpected behavior:
The Y-axis scale and the grid lines should are used to improve the readability of the chart and when using a linear scale the ticks are uniformly spaced with human-readable values (such as multiples of powers of 10).
Computing this evenly spaced and human-readable set of values requires a dataset that reflects the actual values. Applying the
bytes
format after we computed the ticks cases the mentioned issue.For that specific case, I suggest applying the bytes transformation before sending the data into the chart, and use the formatter to only apply a "text" formatting on labels, like adding prefix/suffix etc.
Screenshots (if relevant):
This is the default representation with no format applied
This instead shows the applied
bytes format
. Note the not nicely rounded Y-axis ticks. This happens because the nicely rounded ticks 0, 500, 1500, 2000, are formatted as bytes as they are on that scale, causing the scales to show: 0, 500B, 1000B, 1.46KB, 1.95KB etc. Also notice that's weird why the 500B and 1000B are rounded but not the KB parts)This finally shows
bytes format
+ reducing the decimal fraction to 0:It looks like that there is a difference between 1000B and 1KB, and the step between 1KB and 2KB is smaller than the one from 2KB and 3KB
Errors in browser console (if relevant):
n/a
The text was updated successfully, but these errors were encountered: