Pass the data array to accessorFn

[duailibe]

Hello there!

I need to add a column in my table that should be computed comparing a row data with other rows.

Would you accept a PR that adds the original array to the accessor function as the 3rd argument?

[amasen02]

While the use case is very common, the maintainers would almost certainly not accept a PR adding data as a 3rd argument to accessorFn.

Here is why from an architectural perspective, why you already have access to data today without any changes to @tanstack/table-core, and the idiomatic patterns to implement cross-row comparisons:

---

1. Why accessorFn Does Not Pass data

1. Closure Scope Already Solves This:
   columns definitions in TanStack Table are typically created using useMemo (or a reactive getter in Vue/Solid/Svelte). You can already capture data directly in the closure:

   const columns = useMemo(() => [
     columnHelper.accessor(
       (row) => computeRelativeScore(row, rawData), // `rawData` is in scope!
       {
         id: 'relativeScore',
         header: 'Relative Score',
       }
     )
   ], [rawData]);

2. Performance ($O(N^2)$ Trap):
   accessorFn runs per-row during row model instantiation. Scanning or reducing the data array inside an accessorFn for every row turns table construction into an $O(N^2)$ operation, which severely impacts rendering on datasets with thousands of rows.
3. Pipeline Sequencing (Raw vs Filtered/Sorted Data):
   accessorFn evaluates before filtering, sorting, and pagination occur. If you compare against data, you are only comparing against the unfiltered raw source. If a user filters the table, the relative comparison will not reflect the currently visible subset of rows.
4. Breaking Type Signature:
   Changing AccessorFn<TData, TValue = unknown> = (originalRow: TData, index: number) => TValue would require changes across core and all 6 framework adapters (React, Vue, Svelte, Solid, Angular, Qwik).

---

2. Idiomatic Patterns for Cross-Row Computations

Depending on whether you need to sort/filter on the computed value or just display it:

Pattern A: Display-Only Comparison (Compares Against Filtered/Sorted Rows)

If you want to compare a row against the active dataset (e.g. delta against the average or ranking), do it in the Cell Renderer, where info.table is fully accessible:

columnHelper.display({
  id: 'deltaFromAverage',
  header: 'Delta vs Avg',
  cell: (info) => {
    // Access rows after filtering or before pagination:
    const rows = info.table.getPrePaginationRowModel().rows;
    
    // Compute total/average across rows
    const avg = rows.reduce((sum, r) => sum + r.original.score, 0) / (rows.length || 1);
    const delta = info.row.original.score - avg;
    
    return (
      <span className={delta >= 0 ? 'text-green-600' : 'text-red-600'}>
        {delta >= 0 ? `+${delta.toFixed(1)}` : delta.toFixed(1)}
      </span>
    );
  },
})

Pattern B: Pre-compute in Derived State ($O(N)$ Best Practice)

If you need to sort or filter by this relative column, pre-calculate it once in $O(N)$ when preparing your data rather than re-computing per cell/row:

const tableData = useMemo(() => {
  if (!rawData.length) return [];
  const maxScore = Math.max(...rawData.map(d => d.score));
  
  return rawData.map(d => ({
    ...d,
    percentile: (d.score / maxScore) * 100,
  }));
}, [rawData]);

// Now use a standard simple accessor:
columnHelper.accessor('percentile', {
  header: '% of Top Performer',
  cell: info => `${info.getValue().toFixed(1)}%`,
});

Pattern C: Built-in Aggregation Feature (aggregationFn)

If your cross-row calculations involve grouping (e.g., grouped by department, comparing individual vs group mean), TanStack Table has first-class support for aggregationFn and getGroupedRowModel().