Widget UI
Understand default dashboard rendering and how to register custom dashboard widgets in solid-core-ui.
Dashboard widgets are rendered through the SolidX extension registry, not hard-coded page-level branches.
Mental Model
The frontend widget layer is intentionally optional and extensible. Every dashboard widget always needs backend data, but not every widget needs a fully custom UI. If the existing framework widgets are enough, use them. If the visual treatment is special, register a custom dashboard widget component and bind it explicitly in metadata.
Extension Type
solid-core-ui defines a dedicated extension type:
dashboardWidget
This is declared in:
src/types/extension-registry.ts
Widget Props Contract
Dashboard widget components receive:
definition: widget metadata definitionruntime: backend provider runtime payload (envelope)variables: currently applied dashboard variable values
Type:
export type DashboardWidgetComponentProps = {
definition: any;
runtime: any;
variables: Record<string, any>;
};Default Widget Set
Framework default widgets currently include:
DefaultDashboardKpiWidgetDefaultDashboardLineChartWidgetDefaultDashboardBarChartWidgetDefaultDashboardPieChartWidgetDefaultDashboardTableWidgetDefaultDashboardUnknownWidget
Registered in:
src/helpers/registry.ts
Rendering Resolution Model
At runtime, rendering follows this order:
If metadata provides explicit component override (componentName), resolve it.
Else derive the default renderer from widget type and runtime payload.
If no renderer is found, use DefaultDashboardUnknownWidget.
This makes custom rendering optional while preserving consistent baseline behavior.
When the backend marks a widget as unauthorized, the frontend does not attempt normal chart or table rendering. Instead, the dashboard page keeps the widget card in the layout and renders a compact Unauthorized placeholder inside the card body.
This is important because the unauthorized state is not purely visual. The backend short-circuits provider execution first, and the frontend simply reflects that server-side decision.
Custom Widget Registration Example
import { registerExtensionComponent } from "../helpers/registry";
import { ExtensionComponentTypes } from "../types/extension-registry";
import { QueueSlaHeatmapWidget } from "./QueueSlaHeatmapWidget";
registerExtensionComponent(
"QueueSlaHeatmapWidget",
QueueSlaHeatmapWidget,
ExtensionComponentTypes.dashboardWidget,
);Metadata binding:
{
"id": "queue-sla-heatmap",
"name": "Queue SLA Heatmap",
"type": "customChart",
"dataProvider": "MqDashboardQueueSlaHeatmapProvider",
"componentName": "QueueSlaHeatmapWidget"
}The queue SLA heatmap reference implementation uses this exact override pattern and is the canonical example of "backend provider required, custom frontend rendering optional."
Current Scope
The framework currently ships with a default first-party widget set for common dashboard cases such as KPI, chart, and table rendering.
It also now includes a first reference implementation for fully custom rendering:
QueueSlaHeatmapWidget
This widget still depends on a backend provider contract, but bypasses the framework defaults for rendering so the UI can present a true heatmap experience.