Skip to content
Docs

Building Database Dashboards

Building database dashboards takes three tile kinds and a grid. A dashboard is a tile grid of saved-object references — chart, count-card, and table tiles — persisted as a saved object of type: dashboard.

A saved sankey becomes a dashboard tile — and a navigation surface — Switch the flow's measure from count to revenue, save it, bind a dashboard tile to the saved chart, then click a band to drill into the grid filtered to that exact category pair.
  • Chart — reuses the chart panel in read-only mode. In edit mode every chart tile carries a saved-chart picker: binding points the tile at a saved chart by reference (the tile re-renders whenever the chart is re-saved) and renames the tile after the chart, so a dashboard cannot mislabel what it shows. Clearing the binding falls back to the tile’s built-in configuration.
  • Count card — a single aggregate value plus a label. The value comes from a server aggregate query, never a client-side count.
  • Table — the first N rows of a saved query, linking to the full grid.

Each tile fetches independently through the useFetcher() seam (no direct fetch), with its own loading and error state and an optional per-tile refresh interval.

Edit mode allows drag, resize, add, and remove; view mode exposes none of these affordances — no editable name, no Save/Rename/Delete, no drag handles, and no “New dashboard” control. Drag and resize persist to the definition, so reopening restores each tile’s { x, y, w, h } exactly.

  • A tile whose query throws does not unmount or blank the dashboard — sibling tiles survive.
  • A tile whose referenced saved object was deleted renders a tile-level error naming the missing id, and every other tile still loads. Deleting a saved object performs no cascade delete of dashboards referencing it.