What this prompt does
This prompt specifies a data-heavy fintech transactions table and returns working component code, not pseudocode. It asks for a virtualised table that stays smooth at your row volume with a sticky header, a faceted filter bar (date range, category multi-select, account filter, amount range, status, text search), inline category editing with optimistic update and rollback, and CSV plus PDF export that honours the active filters rather than just the visible page. Money tables are unforgiving, so the prompt locks filter and export behavior before styling.
The variables fit the table to your data. [stack] (for example, Next.js with TanStack Table and shadcn/ui) sets the implementation. [columns] defines exactly which columns render and filter — date, description, category, account, amount, status. [row_volume] drives the virtualisation strategy, because rendering 50k-plus rows smoothly is a different problem than a few hundred. The prompt also asks for a note on how the filters compose into a single query.
When to use it
- You are building a transactions or money table that must stay fast at high row counts
- You need faceted filters: date range, category, account, amount range, status, search
- You want inline category editing with optimistic update and rollback on failure
- You need CSV and PDF export that respects active filters, not just the visible page
- You want full keyboard navigation between cells with enter-to-edit and escape-to-cancel
- You need skeleton loading, empty, and error states plus a result count and filter chips
Example output
The model returns the table component files plus a short note on how the filters compose into a single query. The table virtualises your columns smoothly at the given row volume with a sticky header, a faceted filter bar across all the listed facets, inline category editing with optimistic update and rollback, and CSV/PDF export that respects the active filters. Keyboard navigation, skeleton loading, empty, and error states, a result count, and active-filter chips are all included.
Pro tips
- Set
[row_volume]honestly; the virtualisation approach for 50k-plus rows differs from a small table, and an underestimate produces a janky result - List your exact
[columns]so the filters and inline editing target the right fields - Make export honour the active filters, not the visible page — that mismatch is the bug users report most on money tables
- Match
[stack]to your table library so the virtualisation and filter wiring are usable as-is - Keep the optimistic-update rollback on inline edits; a category change that silently fails erodes trust in the numbers
- Use the active-filter chips and result count so users always know what subset they are looking at and exporting
- Ask for the note on how filters compose into a single query, so date range, category, amount, and search combine predictably rather than fighting each other
