feat(dashboards): Add widget-aware chartcuterie chart type#115312
feat(dashboards): Add widget-aware chartcuterie chart type#115312DominikB2014 wants to merge 3 commits into
Conversation
Adds SLACK_DASHBOARDS_WIDGET, a chartcuterie chart type that accepts a Widget alongside its time series so the server-rendered legend matches what visualizationWidget shows in the dashboard UI. Today the Slack dashboards unfurl renders multi-query widgets without per-query labels, so two queries with the same aggregate collapse into a single legend entry; the new chart type is the rendering half of fixing that. The backend wire-up (sending the new chart type from the Slack unfurl, and the matching Python ChartType enum entry) lands in a follow-up so this PR is FE-only. To keep the FE legend and the chartcuterie legend in lockstep, the label-parts assembly that lived inline in transformWidgetSeriesToTimeSeries is extracted into formatTimeSeriesLabelForWidgetQuery and called by both paths. transformWidgetSeriesToTimeSeries now delegates to it, so a single function owns the alias/conditions/field-alias/yAxis-suffix rules. timeseries.tsx is restructured around a shared buildTimeseriesChartOption so SLACK_TIMESERIES and SLACK_DASHBOARDS_WIDGET share axes, legend, palette, sort, isOther handling, and stacking — the only thing each chart type customizes is the per-series plottable factory. The dashboards renderer pairs each TimeSeries with its widget query via a [TimeSeries, widgetQueryIndex] tuple shape because a single widget query can yield multiple TimeSeries (multi-aggregate, topEvents, yAxis=[...]), so positional zipping against widget.queries doesn't work in general. Co-Authored-By: Claude <noreply@anthropic.com>
github-actions
Bot
added
the
Scope: Frontend
📊 Type Coverage Diff
🔍 1 new type safety issue introducedType assertions (
This is informational only and does not block the PR. |
Co-Authored-By: Claude <noreply@anthropic.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 8842f07. Configure here.
| alias, | ||
| undefined, | ||
| color | ||
| ); |
There was a problem hiding this comment.
Widget-aware label not shown in chart legend
High Severity
The formatted widget-aware label is passed as alias to createPlottableFromTimeSeriesAndWidget, but name is passed as undefined. ECharts uses the series name (from the plottable's name getter) for the chart legend, not the alias/label. Since name is undefined, it falls back to formatTimeSeriesName, which produces raw unformatted names like "count(span.duration)" instead of the intended widget-aware labels like "DB spans : count(spans)". The alias only populates the label getter used for tooltips, which don't exist in chartcuterie's static image output. The alias value likely needs to also be passed as name.
Reviewed by Cursor Bugbot for commit 8842f07. Configure here.
There was a problem hiding this comment.
Seems like a legit comment?
narsaynorath
left a comment
narsaynorath
left a comment
There was a problem hiding this comment.
Looks good, aside from the undefined series name comment. The extension to support dashboard widgets is nice and compact this way with the helpers.
2 participants
timeSeriesconfig, but eventually realized we need access to the widget itself to do various things like label formatting from the alias, and thresholds. This can be done in the backend, but i'd prefer to reuse FE code if possible.timeSeriesconfig to accept acreatePlottablefunction, this let's us control thetimeseries -> plottablebehaviour while still sharing most of the code betweentimeserieanddashboardsWidgetchartcuterie config.Out of scope
This PR is FE-only. The Slack unfurl wire-up (switching
ChartType.SLACK_TIMESERIEStoChartType.SLACK_DASHBOARDS_WIDGET, serializing the widget, building the tuples) plus the matching PythonChartTypeenum entry land in a follow-up backend PR. Thresholds (which the widget model already carries) will also build on this chart type in a separate PR.