0.5.1 — Create view is a modal with a live record preview

What's new

Create view modal with live record preview

Before 0.5.1, creating a saved view meant typing a name into an inline form and then editing filters / sort afterward — a two-step flow that hid what the view would actually show until it was already saved. 0.5.1 replaces that with CreateViewModal: a centered frosted panel that puts the whole view configuration in one place, next to a live record preview that updates as you edit.

• One modal, three entry points. The sidebar tree's Create view row, the New view entry in the grid header's ViewSelect dropdown, and the New view entry in the medium DataTableViewerWidget canvas widget's dropdown all open the same modal. The old inline NewViewForm is deleted.
• Live preview. A header line reads "123 of 951 records match" and re-computes as the draft filter tree or sort list changes. Below it, up to 50 matching records render as a compact grid using the underlying table's visible columns (extra matches indicated with a "showing 50 of N" footer). Preview counts flow through the grid's own applyTableFilters / applyTableSorts engines via a computePreview callback, so the number the modal shows is exactly the number the created view will show — link resolution, tag assignments, child-link rollups, and week-start all match.
• Seeded from the grid. The modal opens with the grid's current filters and sort as its draft, preserving the "filter the grid, then save what I see" muscle memory. Everything stays editable in the modal.
• Full column pool. The filter and sort editors use buildFilterableCols — the same column pool the Edit View sheet uses — so the medium canvas widget is no longer capped to its four displayed columns when building a view.
• Tags correctness. A tags-column filter in the draft prefetches tag assignments through the refactored ensureTagAssignments before the preview counts, so tag-filtered previews can't silently under-count.
• Create = save + apply. On success the grid applies the new view's filters + sort, resets to page 0, and marks it active (not dirty). useTableViews.createView now accepts explicit draft filters / sorts alongside the legacy live-snapshot signature that keeps older call sites working.
• Escape / backdrop / Cancel all close without saving; errors from the create RPC surface inline in the modal.

See Data → Create view modal.

Under the hood

• CreateViewModal.jsx (new) — modal component. The filter and sort engines still live in DataTableViewerWidget, so the widget passes a computePreview callback down instead of the modal importing the engines directly. This is the same cycle-avoidance rule that moved SortListEditor / TableFilterValueInput / makeSortId into shared/tableSortFilterEditors.jsx in 0.5.0.
• useTableViews.createView now accepts an optional { filters, sorts } draft. When supplied, the draft is normalized (same sort-shape validation as ViewSettingsSheet.save) and persisted directly; when omitted, the legacy path snapshots the widget's live filters and sorts, so pre-modal call sites keep working unchanged.
• ensureTagAssignments refactored so it takes a filter tree and prefetches tag data for any tag-column rules found inside — called from the modal on every draft change so the live count can never under-report tag-filtered matches.
• ViewSelect delegates the create action to the parent via onStartCreate. The dropdown's footer button and empty-state hint both point at "+ New view", opening the modal.
• DataTableListBody — the sidebar tree's create row hands off to the same parent handler; the inline form and its own state are gone.

What's next

The medium canvas DataTableViewerWidget still renders its own condensed toolbar; a follow-up will bring its edit-view sheet onto the same modal-shaped canvas so create and edit feel like one surface.

See Data → Saved views.