M1: A Data-Intensive Web App

// v1, in full: fetch all, filter in memory, virtualised rows, client-side CSV. right at 10k rows; known to die at ~150k
function Transactions() {
  const { data: rows = [] } = useQuery({ queryKey: ['transactions'], queryFn: () => api.transactions.all(), staleTime: 60_000 })
  const [filter, setFilter] = useState({ status: 'all', q: '' }); const [sort, setSort] = useState({ by: 'date', dir: 'desc' })
  const visible = useMemo(() => sortRows(filterRows(rows, filter), sort), [rows, filter, sort])   // 2 ms at 10k; 200 ms at 1M
  const virt = useVirtualizer({ count: visible.length, getScrollElement: () => ref.current, estimateSize: () => 36 })
  return <>
    <Filters value={filter} onChange={setFilter} />
    <div ref={ref} className="scroll">{virt.getVirtualItems().map(v => <Row key={visible[v.index].id} row={visible[v.index]} style={{ transform: `translateY(${v.start}px)` }} />)}</div>
    <button onClick={() => downloadCsv(visible)}>Export</button>
  </>
}
// the numbers v1 lives within: rows × 200 B × 3 < 100 MB (≈150k rows on a laptop); fetch < 2 s; filter < 200 ms. write them in the file header.

// v2: the server holds the data; the client holds filter + sort + cursor + one page
const key = ['transactions', { filter, sort, cursor }]
const { data, isPending, isPlaceholderData } = useQuery({
  queryKey: key, queryFn: ({ signal }) => api.transactions.page({ filter, sort, cursor, limit: 50 }, { signal }),
  placeholderData: keepPreviousData,       // the old page stays visible while the new one loads: no flash to empty
  staleTime: 30_000,
})
// filter change: wrap in startTransition so typing in the filter box stays responsive while the page refetches and re-renders
// cursor: data.nextCursor; "previous" via a cursor stack in state; "jump to date" is a filter (date_gte), not a page number
// the server: WHERE from the filter (validated against an allowlist of columns), ORDER BY (sort col, id) with a composite index per sort,
//   keyset condition from the cursor, LIMIT 51; the cursor is base64 of the last row's (sort value, id)
// counts: a separate query ['transactions','count',{filter}] with a longer staleTime; shown as "about 1.2M" when expensive (an estimate from stats)

// v5: freshness without jumping the user's page
// "new rows above" indicator: poll (or subscribe, M8) to a count of rows newer than the page's newest, under the same filter
const { data: newer } = useQuery({ queryKey: ['transactions', 'newer', { filter, since: page.newestAt }], queryFn: …, refetchInterval: 30_000 })
// render: newer > 0 && <button onClick={() => { setCursor(null); scrollTop() }}>{newer} new transactions</button>
// the page itself does not change under the user; new data is an offer. on focus: refetch the current page only (same cursor) so edits to visible rows appear.
// row-level updates (a status changed by someone else): with normalisation (v3), a subscription that delivers entity patches updates the row in place;
//   without it, the focus refetch covers it within the freshness requirement
// what not to do: refetchInterval on the page query itself with a cursor: rows shift under the user's pointer; a click lands on the wrong row