(v9) Sparse row model for remote tables: scroll to any row

[JimKnoxx]

We have a remote table. The server has 100,000 rows, and we load 50 rows at a time. The server also tells us the total row count. We set count to it. Now the scrollbar has the correct length, and the user can drag it to the end.

But then the app loads page after page. The loading animation continues until the app has loaded all rows up to the scroll position. To show row 99,999, the app must load 2,000 pages, one after the other. If each page takes 300 ms, the user waits 10 minutes. The server also sends 99,950 rows that the user does not want to see.

The cause is that data cannot have gaps:

• If the app loads only the last page, these rows become rows 0 to 49. getRowModel().rows[i] is then not row i on the server.
• getRowId gets no data for a row that is not loaded.
• To fill the gaps, we must use fake objects. The table cannot tell a fake object from a real row.

Idea: an opt-in feature that uses rowCount as the total. The table shows a placeholder row for each row that is not loaded. The table does not load data. It tells the app which ranges are missing, and the app loads them, for example with TanStack Query. For a jump to row 99,999, the app loads only the visible rows, not 2,000 pages.

const table = useTable({
  features: tableFeatures({ sparseRowsFeature }),
  columns,
  data: loadedRowsByIndex,
  rowCount: 100_000,
  getRowId: (row) => row.id,
})

table.getRowModel().rows[99_999].getIsPlaceholder() === true
table.getMissingRowRanges({ startIndex: 99_950, endIndex: 99_999 })

A placeholder row has a temporary ID. The table keeps no selection, pinning, or expanding state for it.

The feature needs two things from the server: the total row count and rows by offset. Without them, the current infinite scrolling pattern stays the correct choice.

Related: #2385

[mohamadgarmabi]

+1, and it pairs naturally with #6658: exclude-mode selection over rows that were never loaded only makes sense if the table also accepts that rows can be missing.

Some things the design probably needs to pin down:

1. Sorting / filtering reset the index space. Row 99,999 under one sort is a different row under another. Loaded rows and missing ranges should be tied to the current sorting + columnFilters + globalFilter, and cleared when any of them change. That also means the feature only makes sense with manualSorting / manualFiltering; client-side row models over a sparse array would give wrong results.
2. Offset drift. If rows are inserted or deleted on the server between two block loads, offset-based pages overlap or leave a hole, and the same ID can appear at two indexes. A dev-mode warning on duplicate getRowId results would make this visible. Apps that care can pass a snapshot/cursor ID with each block request.
3. getMissingRowRanges granularity. Returning ranges aligned to a block size (e.g. blockSize: 50) instead of exact gaps makes the result directly usable as a cache key, so the same block isn't requested twice with slightly different bounds.

Until something like this lands, you can get the same UX in userland by virtualizing over rowCount instead of over the table's rows, and loading only the visible blocks with TanStack Query:

const BLOCK = 50
const virtualizer = useVirtualizer({
  count: rowCount, // full server count, not data.length
  getScrollElement: () => scrollRef.current,
  estimateSize: () => 36,
  overscan: 10,
})
const items = virtualizer.getVirtualItems()
const firstBlock = Math.floor((items[0]?.index ?? 0) / BLOCK)
const lastBlock = Math.floor((items.at(-1)?.index ?? 0) / BLOCK)

const blocks = useQueries({
  queries: Array.from({ length: lastBlock - firstBlock + 1 }, (_, i) => {
    const block = firstBlock + i
    return {
      queryKey: ['rows', sorting, filters, block],
      queryFn: ({ signal }) =>
        fetchRows({ offset: block * BLOCK, limit: BLOCK, sorting, filters, signal }),
      staleTime: 60_000,
    }
  }),
})

// index -> loaded row (or undefined = render a skeleton row)
const rowAt = (index: number) =>
  blocks[Math.floor(index / BLOCK) - firstBlock]?.data?.[index % BLOCK]

Pass only the loaded rows as data (with getRowId) and render each virtual item with table.getRow(id) when rowAt(index) exists, or a skeleton otherwise. Dragging the scrollbar to the end then fetches one or two blocks instead of 2,000. Because the queryFn uses signal, blocks the user scrolls past before they finish get cancelled.

The limit of the userland version is exactly what this proposal fixes: the table itself doesn't know the real index of a row, so keyboard navigation, getRowModel().rows[i], and range selection all have to be rebuilt around rowAt.