Uh oh!
There was an error while loading. Please reload this page.
Add Airtable Dashboard gap analysis documentation - #715
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Pull request overview
Adds an Airtable vs ObjectStack dashboard gap-analysis guide and integrates a phased implementation plan into the project roadmap so upcoming protocol/objectui work can be tracked against concrete parity targets.
Changes:
- Added a new guide
airtable-dashboard-analysis.mdxcovering UI zone breakdown, protocol/component gaps, examples, and a phased roadmap. - Registered the new guide in
content/docs/guides/meta.jsonnavigation. - Added a new “Dashboard Enhancement — Airtable Dashboard Parity” section to
ROADMAP.mdwith linked issues and effort estimates.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| content/docs/guides/meta.json | Adds the new guide to the Guides sidebar order. |
| content/docs/guides/airtable-dashboard-analysis.mdx | New MDX guide documenting dashboard parity gaps, proposed schema changes, component work, examples, and roadmap. |
| ROADMAP.md | Introduces a dedicated dashboard parity roadmap section and updates section numbering/links accordingly. |
| field: 'product_line', | ||
| label: 'Product Line', | ||
| type: 'select', | ||
| optionsFrom: { | ||
| object: 'product', | ||
| valueField: 'category', | ||
| labelField: 'category' | ||
| }, | ||
| scope: 'dashboard' | ||
| } |
There was a problem hiding this comment.
optionsFrom is described here as being “for lookup type”, but the example uses type: 'select' together with optionsFrom. This is internally inconsistent in the doc and could confuse implementers; either change the example to type: 'lookup' or update the proposed GlobalFilterSchema docs to state that optionsFrom is supported for select as well.
| object: 'opportunity', | ||
| valueField: 'amount', | ||
| aggregate: 'sum', | ||
| filter: { field: 'stage', operator: 'eq', value: 'closed_won' }, | ||
| colorVariant: 'orange', | ||
| actionUrl: '/reports/revenue-detail', | ||
| actionType: 'internal', | ||
| layout: { x: 0, y: 0, w: 4, h: 2 } | ||
| }, | ||
| { | ||
| title: 'Win Rate', | ||
| description: 'Percentage of opportunities closed won', | ||
| type: 'kpi', | ||
| object: 'opportunity', | ||
| valueField: 'stage', | ||
| aggregate: 'count', | ||
| colorVariant: 'teal', | ||
| actionUrl: '/reports/win-rate', | ||
| actionType: 'internal', | ||
| layout: { x: 4, y: 0, w: 4, h: 2 } | ||
| }, | ||
| { | ||
| title: 'Active Deals', | ||
| description: 'Opportunities in pipeline', | ||
| type: 'metric', | ||
| object: 'opportunity', | ||
| valueField: 'id', | ||
| aggregate: 'count', | ||
| filter: { | ||
| field: 'stage', | ||
| operator: 'nin', | ||
| value: ['closed_won', 'closed_lost'] | ||
| }, |
There was a problem hiding this comment.
The examples use a { field, operator, value } shape for filter, but DashboardWidgetSchema.filter is typed as FilterConditionSchema (ObjectStack query DSL like { status: { $eq: 'paid' } } / { is_closed: false }). Even though the current Zod schema is permissive, keeping examples aligned with the canonical filter DSL will avoid confusion and match existing tests/usages.
| import { Dashboard } from '@objectstack/spec'; | ||
| export const salesPerformanceDashboard = Dashboard.create({ |
There was a problem hiding this comment.
The TypeScript example imports Dashboard from @objectstack/spec, but the package root only exports protocol namespaces (e.g. UI) and a few DX helpers. As written, this import won't work; use import * as UI from '@objectstack/spec/ui' (or import { UI } from '@objectstack/spec') and reference UI.Dashboard.create(...) / the subpath export instead.
| import { Dashboard } from'@objectstack/spec'; | |
| exportconst salesPerformanceDashboard =Dashboard.create({ | |
| import { UI } from'@objectstack/spec'; | |
| exportconst salesPerformanceDashboard =UI.Dashboard.create({ |
| chartConfig: { | ||
| series: [ | ||
| { name: 'closed_won', label: 'Won', color: '#10b981' }, | ||
| { name: 'closed_lost', label: 'Lost', color: '#ef4444' } | ||
| ] | ||
| }, | ||
| layout: { x: 0, y: 6, w: 6, h: 4 } |
There was a problem hiding this comment.
Several examples use chartConfig without the required type field. ChartConfigSchema currently requires type: ChartTypeSchema, so these snippets won’t validate as-is. Either include type in the examples (matching the widget’s type) or clarify that the schema would need to be adjusted to infer it from the widget.
| chartConfig: { | ||
| xAxis: { field: 'close_date', format: 'MMM YYYY' }, | ||
| yAxis: { field: 'amount', format: '$0,0' }, | ||
| series: [ |
There was a problem hiding this comment.
In the full dashboard example, chartConfig.yAxis is shown as a single object, but ChartConfigSchema defines yAxis as an array of axes. This example won’t validate against the current schema unless yAxis is changed to an array (even for a single axis).
Documents protocol and component gaps between ObjectStack dashboards and Airtable's Sales Performance interface. Provides implementation roadmap with effort estimates and issue references.
Documentation Added
content/docs/guides/airtable-dashboard-analysis.mdxcolorVariant/actionUrlon widgets,optionsFromon globalFilters,headerconfig,pivotConfigwith multi-measureDashboardFilterBar,MetricCardvariants,PivotTable, widget header actions, advanced charts (funnel/grouped-bar/gauge)Roadmap Integration
ROADMAP.mdSection 8.2 — Added dashboard enhancement phases with effort estimates, priority levels, and links to tracking issues (#712-714, objectui#585-588)Example Enhancement
Current widget schema lacks visual variants and actions:
Proposed enhancement adds color theming, descriptions, and navigation:
Original prompt
This pull request was created from Copilot chat.
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.