Found while repairing chart-config-missing's over-reach for #14436 (PR #15461). Out of scope there: that card is about a rule that fires when it should not; this is the opposite gap, in the same rule file, and it needs its own id and message.
What is unreported
validateWidgetBindings (packages/lint/src/validate-widget-bindings.ts) reports nothing about two dataset-bound chart widget shapes that the pinned renderer visibly degrades. Read at the @object-ui revision this repo pins (.objectui-sha = 00d3f09c500c4a45b5f27aca8af80349412faaf1):
- A chart-type widget that selects NO measures.
DatasetWidget.tsx:683 short-circuits to an authoring placeholder — "Pick measures (values) for this dataset widget." — before any query runs. No chart is drawn at all. Rules (b)/(c) of the widget-binding family iterate dimensions[] / values[] and so are silent on empty arrays; table-count-only requires values.length > 0. Nothing else looks.
- A chart-family widget that selects NO dimensions.
DatasetWidget.tsx:423 — const isMetric = METRIC_TYPES.has(widgetType) || dimensions.length === 0; — so a bar or pie with no dimensions renders as a single-value KPI number, not the family the author asked for. Silent: the tile shows a plausible number, which is the failure direction the family's own docblock calls out ("a missing number reads as zero, and zero is the answer the manager is hoping for" — here it is worse, because the number is real and the chart is simply gone).
Why these are not chart-config-missing
Neither is caused by, nor repairable with, chartConfig. The pinned renderer derives the axis key and one series per measure from dimensions / values and refuses an authored ChartAxis.field / ChartSeries.name, and chart-field-unknown in the same file errors on a yAxis[].field naming anything the widget did not select — so chartConfig can never supply a measure the values array is missing. Folding these two shapes in under chart-config-missing would leave that id misnaming its own condition, which is why #15461 deliberately left them out and documented the omission in the rule's docblock instead.
Decision this needs
Whether either shape is worth a rule, and at which tier, is a judgement rather than a measurement:
- Shape 1 is arguably schema-level: is an empty
values on a chart-type widget an authoring error the spec should refuse outright, or a work-in-progress state a build should tolerate? If it is a lint finding, error looks right — the renderer draws nothing.
- Shape 2 is more clearly warning-tier: the widget renders and the number is correct, but the author's declared chart family is silently ignored. Possibly the honest repair is to steer the author to
metric rather than to add a dimension.
Both would be new ids in the widget-binding family, not new arms of an existing one.
Filed unassigned and unlabeled for triage — not started, no branch.
Generated by Claude Code
Found while repairing
chart-config-missing's over-reach for #14436 (PR #15461). Out of scope there: that card is about a rule that fires when it should not; this is the opposite gap, in the same rule file, and it needs its own id and message.What is unreported
validateWidgetBindings(packages/lint/src/validate-widget-bindings.ts) reports nothing about two dataset-bound chart widget shapes that the pinned renderer visibly degrades. Read at the@object-uirevision this repo pins (.objectui-sha=00d3f09c500c4a45b5f27aca8af80349412faaf1):DatasetWidget.tsx:683short-circuits to an authoring placeholder — "Pick measures (values) for this dataset widget." — before any query runs. No chart is drawn at all. Rules (b)/(c) of the widget-binding family iteratedimensions[]/values[]and so are silent on empty arrays;table-count-onlyrequiresvalues.length > 0. Nothing else looks.DatasetWidget.tsx:423—const isMetric = METRIC_TYPES.has(widgetType) || dimensions.length === 0;— so abarorpiewith no dimensions renders as a single-value KPI number, not the family the author asked for. Silent: the tile shows a plausible number, which is the failure direction the family's own docblock calls out ("a missing number reads as zero, and zero is the answer the manager is hoping for" — here it is worse, because the number is real and the chart is simply gone).Why these are not
chart-config-missingNeither is caused by, nor repairable with,
chartConfig. The pinned renderer derives the axis key and one series per measure fromdimensions/valuesand refuses an authoredChartAxis.field/ChartSeries.name, andchart-field-unknownin the same file errors on ayAxis[].fieldnaming anything the widget did not select — sochartConfigcan never supply a measure thevaluesarray is missing. Folding these two shapes in underchart-config-missingwould leave that id misnaming its own condition, which is why #15461 deliberately left them out and documented the omission in the rule's docblock instead.Decision this needs
Whether either shape is worth a rule, and at which tier, is a judgement rather than a measurement:
valueson a chart-type widget an authoring error the spec should refuse outright, or a work-in-progress state a build should tolerate? If it is a lint finding,errorlooks right — the renderer draws nothing.metricrather than to add a dimension.Both would be new ids in the widget-binding family, not new arms of an existing one.
Filed unassigned and unlabeled for triage — not started, no branch.
Generated by Claude Code