Uh oh!
There was an error while loading. Please reload this page.
fix(charts): a grouped chart whose SECOND dimension was never projected says so - #4696
Merged
Merged
Conversation
…ed says so
"Cannot know refuses loudly" was answered on the first dimension only.
`hasNoCategoryKey` (framework#4033) names an unprojected x-axis dimension
instead of drawing a bare axis; the series axis had no counterpart, so a pivot
whose second dimension was absent from the result rows produced `series: []`
and rendered axes, grid, tooltip and legend around zero marks - to the author,
indistinguishable from "no data matched".
The signal is `buildChartSeries`' own output (`series: []` with rows to draw
against), NOT `groupKey in row` - which is objectui#4507's trap inverted: this
component is handed the PIVOTED bucket rows, whose columns are the group's
VALUES, so the second dimension's key is a column of no pivot ever and such a
test would refuse every grouped chart in the product.
Limited to the families whose marks come from `series` and nothing else (bar,
horizontal-bar, line, area, combo) - measured in this file: pie, donut, funnel,
radar, scatter, treemap and sankey fall back to `series[0]?.dataKey || 'value'`
and draw a working chart with no series at all, where a refusal would blank it.
The message names the failure and BOTH authoring causes rather than the group
key, because the renderer is not told it and the two upstream shapes are
byte-identical: an unprojected second dimension and a chart with no measure
selected both return `{data:[{status:'Backlog'},...], xAxisKey:'status',
series:[]}`. Naming one would be a sentence that is false half the time.
The three-way distinction stays pinned: null / empty-string groups DRAW
(objectui#4673), a partially projected key draws what projects - mirroring
`hasNoCategoryKey`'s own `!rows.some(...)` - and an ordinary pivot is unchanged.
Fixes#4683
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RnQd8iMMUwXQEV1crFmQiQThe latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
This was referenced Aug 15, 2026
yinlianghui
marked this pull request as ready for review
August 15, 2026 10:49
Uh oh!
There was an error while loading. Please reload this page.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes#4683
Verified at HEAD
bf0d7351e.What was wrong
"Cannot know refuses loudly" was answered on the first dimension only.
AdvancedChartImpl'shasNoCategoryKey(framework#4033) names an unprojected x-axis dimension instead of drawing a bare axis. The series axis had no counterpart, so a pivot whose SECOND dimension was absent from the result rows producedseries: []and rendered axes, grid, tooltip and legend around zero marks. To the author that reads as "no data matched", when what happened is that a dimension they grouped BY never arrived.Measured on this branch's own fixture with the guard reverted: an svg,
0.recharts-rectangleelements, no warning, no text.The signal, and the one it is deliberately not
The guard reads
buildChartSeries' own output —seriesis an array that came out empty, and there are rows to draw against.It does NOT read
groupKey in row, which is #4507's trap inverted. This component is handed the PIVOTED bucket rows, whose columns are the group's VALUES, so the second dimension's own key is a column of no pivot ever — ordinary ones included. A key-in-row test here would refuse every grouped chart in the product. #4507 is its own card and is not addressed here; nothing in this PR touches the first dimension's guard beyond extracting the placeholder shell both refusals now render.The refusal is limited to the families whose marks come from
seriesand nothing else — bar, horizontal-bar, line, area, combo. Measured in the file rather than assumed: pie, donut, funnel, radar, scatter, treemap and sankey all fall back toseries[0]?.dataKey || 'value'and draw a working chart with no series declared at all, so a refusal there would blank a good chart instead of explaining a broken one. That set is narrower than the existingCATEGORY_AXIS_CHART_TYPES, and the difference is load-bearing.Why the message does not name the group key
hasNoCategoryKeynames the key it could not find. This one cannot, and saying so is the honest answer rather than a limitation worked around. The renderer is not told which dimension the pivot grouped by, and the two upstream shapes that reach it are byte-identical — measured:Naming one cause would print a sentence that is false half the time, which is worse than the silence it replaces. So the copy names the failure and BOTH authoring causes, and the console warning carries the same diagnostic pair the model prints: the axis the chart did plot, and the keys its rows actually carry. In the card's shape that second half is the tell — bucket rows carrying the category and nothing else.
Plumbing the pivoted dimension into the renderer would allow a key-naming message; it is costed as an open question in the report rather than taken unilaterally, because it spans three packages and introduces a prop a future call site can forget — the blindable-guard class #4507 is about.
The three-way distinction, each arm pinned
seriesnon-empty, guard silent (buildChartSeries' pivot branch silently drops a null SECOND-dimension group: its measure is written to the bucket but never becomes a series, so the value vanishes from the chart #4673 intact, its suite untouched and green);Also pinned: the x-axis refusal wins when both apply (one cause, one diagnosis, one warning);
series === undefinedis left byte-for-byte alone; an empty result set is still the chart's own empty state.Copy and i18n convention
Mirrors the model exactly, measured first: the framework#4033 guard produces a hardcoded English string in JSX plus a hardcoded
console.warn, with no locale key. This guard matches that convention, so no locale-pack key was added andcheck:i18n-keys/check:i18n-driftstay clean.Verification (HEAD
bf0d7351e, clean tree)pnpm exec vitest run packages/core/ packages/plugin-charts/117 passed (117)files,2073 passed (2073)tests11 passed (11)pnpm exec vitest run packages/plugin-dashboard/(downstream consumer of plugin-charts, run by name)58 passed (58)files,462 passed (462)pnpm --filter '@object-ui/plugin-charts^...' buildthenpnpm --filter @object-ui/plugin-charts type-checktype-check, nottypecheck)pnpm exec eslint --quieton both changed filesnode scripts/check-changeset-presence.mjspnpm run check:control-bytescheck:i18n-keys/check:i18n-drift/check:phantom-depsReverse verification, direction predicted before running: ablate the guard (
git checkout origin/main -- AdvancedChartImpl.tsxfrom the committed state) and exactly the three refusal-arm tests go red while the eight draw/unchanged pins stay green. Observed:3 failed | 13 passedacross the ablated pair of files — the predicted three, named placeholder, warning, family sweep. Restored from the branch and re-run green.One flaky failure appeared in the first plugin-dashboard sweep (
DatasetWidget.dottedDimension.test.tsx:269,expected [] to deeply equal [ 'crm_opportunity' ]). Measured on both sides — ablated full suite green, restored full suite green, file alone green — so it is not this change. It is the second site of the race already filed as #4487, and is attached there rather than re-filed.Findings filed
series: []#4695 — a cartesian chart handed no series binding at all (series === undefined) draws the same silent empty frame. Unassigned,findinglabel, deliberately outside this card's guard; the current behaviour is pinned by a test here so nobody discovers it as a silent contradiction.#4692 remains open and is untouched; the click-handler region #4694 landed was not edited.
Generated by Claude Code