Conversation
When a numeric value is smaller than the minimum representable value at the current precision (< 0.0001), the field renderer was silently rounding it to 0. This was misleading — e.g. the Jobs widget showed "0 failed jobs" when the actual rate was tiny but nonzero. Now values in the range (0, 0.0001) are displayed as scientific notation with 2 significant digits (e.g. 3.3e-5). In table cells, a tooltip on hover shows the full-precision value. The same fix is applied to ECharts tooltip formatting. The minimum-value threshold is derived from the existing NUMBER_MAX_FRACTION_DIGITS constant so there are no new magic numbers. Fixes DAIN-1378 Co-Authored-By: Claude <noreply@anthropic.com>
…table Mirrors the tooltip behavior added to fieldRenderers.tsx: when a numeric value in the breakdown legend table is smaller than NUMBER_MIN_VALUE, wrap the scientific notation in a Tooltip that shows the full value on hover. Co-Authored-By: Claude <noreply@anthropic.com>
…values Replace the scientific notation display (e.g. 3.3e-5) with a simpler threshold indicator (<0.0001) for values below NUMBER_MIN_VALUE. This is more readable for users who may not be familiar with scientific notation. Tooltip titles use toLocaleString() instead of toString() so the hover value is also locale-formatted. Co-Authored-By: Claude <noreply@anthropic.com>
github-actions
bot
added
the
Scope: Frontend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
…d table Introduce a purpose-built formatter for the breakdown legend table under charts, replacing the reuse of formatTooltipValue (which is scoped to ECharts hover tooltips). The new formatter handles null values (em dash) and delegates everything else to formatTooltipValue. Also adds the missing dataType === 'number' guard on the small-value Tooltip in the legend table, so the tooltip is not incorrectly applied to duration, rate, and other non-number types. Co-Authored-By: Claude <noreply@anthropic.com>
Member
Author
|
@cursor review |
static/app/views/dashboards/widgets/timeSeriesWidget/formatters/formatTooltipValue.tsx
Show resolved
Hide resolved
DominikB2014
approved these changes
Mar 23, 2026
Contributor
DominikB2014
left a comment
DominikB2014
left a comment
There was a problem hiding this comment.
Cursor comment seems plausible? but otherwise lgtm
…and tooltip The legend and chart tooltip serve different purposes, so small "number" values (< 0.0001) should be formatted differently in each context: - Legend: shows "<0.0001" — space-constrained, threshold indicator is enough - Chart tooltip: shows full precision with 4 significant digits (e.g. "0.00003345") — the tooltip's purpose is to show detail, so "<0.0001" would be actively misleading there Also escapes the valueFormatter return value in timeSeriesWidgetVisualization to prevent HTML injection, matching the existing escaping on nameFormatter. Co-Authored-By: Claude <noreply@anthropic.com>
…downLegendValue After the null check, `value` is still `number | string` because ECHARTS_MISSING_DATA_VALUE is a string constant. Add a `typeof value === 'number'` guard to narrow the type before the `>` and `<` comparisons. Co-Authored-By: Claude <noreply@anthropic.com>
Member
Author
|
@cursor review |
The tooltip on small number values in table cells was calling toLocaleString() directly. It should use formatTooltipValue instead, which applies the same 4-significant-digit precision formatting that chart tooltips use for small numbers. Co-Authored-By: Claude <noreply@anthropic.com>
Member
Author
|
@cursor review |
gggritso
deleted the
georgegritsouk/dain-1378-when-values-are-very-small-theyre-shown-as-0-rather-than
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a numeric value is very small (less than 0.0001), the field renderer and dashboard widgets were silently rounding it to 0 due to fractional digit capping. This was misleading — e.g. the Jobs widget could show "0 failed jobs" when the actual rate was tiny but nonzero.
e.g.,
Values below the minimum representable threshold now display as
<0.0001instead of0. A tooltip on hover shows the locale-formatted actual value so users can still see the precise number if needed. This is the pattern we also follow for other value types, like rates.e.g.,
Longer term, when we come back and talk about how we want to format numbers across the product, we'll come back to this decision. There's a decent chance we'll be using scientific notation, for example.
Fixes DAIN-1378