Dashboard
The dashboard and all six built-in widget types ship in habarico-enterprise — they read the
aggregate endpoint, which only a paid backend serves. Install it and render EnterpriseSchemaAdmin
instead of SchemaAdmin:
import {EnterpriseSchemaAdmin} from 'habarico-enterprise';
<EnterpriseSchemaAdmin schemaProvider={…} authProvider={…} />;
EnterpriseSchemaAdmin supplies the paid data and schema providers itself, so neither has to be
named.
Or wire it yourself: dashboard={SchemaDashboard} on SchemaAdmin, with
dataProviderFactory={getEnterpriseDataProviderFactory} and
schemaProviderFactory={getEnterpriseSchemaProvider} — without those two the widgets
render their unsupported state, because the endpoints behind them are not reachable. The widget catalogue needs no
prop — it comes from WidgetCatalogContext in the same package, which defaults to
enterpriseWidgetProvider / enterpriseWidgetTypes. Without the dashboard prop SchemaAdmin
mounts no dashboard at all; it has no default.
The grid the dashboard is built on (DashboardGrid), the layout store (useDashboardStore) and
the WidgetType / WidgetConfig vocabulary stay in the free package, mirroring the
preferences.dashboard store that both backends keep free. Resolving a type to a widget
(useGetWidget, WidgetCatalogProvider) is paid, together with the dashboard that calls it.
The dashboard is a grid of widgets: the backend decides which resources may be queried and how, the frontend renders the widgets and remembers each user's layout.
| Page | What it covers |
|---|---|
| SchemaDashboard | The dashboard component |
| Widget types | Built-in widget types |
| Data sources | Where a widget's data comes from |
| Widget configuration | The add-widget wizard, and how layouts persist |
| Adding a new widget type | Registering your own widget |
See also
- Dashboard — enabling dashboard and aggregate access on the Python side
- Aggregations — the endpoint the chart widgets read
- Aggregation (Ruby) — the same two flags on a Rails backend