getGroupingValue takes the original row only

[dvmoritzschoefl]

Currently, it seems that the code for getting the grouping value does this

  if (!column.columnDef.getGroupingValue) {
    return row.getValue(columnId)
  }

  if (row._groupingValuesCache) {
    row._groupingValuesCache[columnId] = column.columnDef.getGroupingValue(
      row.original,
    )
  }

which means it passes the original row only. Our problem is that we rely on accessor functions as data mapping mechanism, and this architecture prevents us from defining a custom groupingValue and an accessor function at the same time, since you need the row index (of the row, not the original) to call the accessor function.

We currently have a workaround involving a cache to make the values returned by the accessor function stable, but this seams suboptimal.

Would it be a useful addition for the table to pass the row instead of row.original or does this has some side effects i am not aware of?

[mg1986jp]

Yeah, this is a real limitation. getGroupingValue receives row.original because it was designed to compute grouping keys from raw data before the row model processes things like accessors. But if your accessor does non-trivial mapping (lookups, computed values), you end up duplicating that logic or maintaining a cache like you're doing.

The cleanest workaround without patching the library: compute the mapped values upfront and store them on the original data. Instead of relying on the accessor to do the mapping at render time, pre-process your data array before passing it to useReactTable:

const processedData = useMemo(() =>
  rawData.map((item, index) => ({
    ...item,
    _mappedValue: computeValue(item, index), // whatever your accessor does
  })),
  [rawData]
);

Then your getGroupingValue just reads row._mappedValue and the accessor reads the same field. Single source of truth, no cache needed.

If that doesn't fit your architecture (e.g. the mapping depends on other table state), then passing the full Row instead of row.original would be the right API change. It shouldn't cause issues since Row has .original on it anyway — existing code calling getGroupingValue(row.original) would just need to be updated to getGroupingValue(row) with users accessing row.original themselves. Might be worth opening a feature request / PR for that.

[dvmoritzschoefl]

It would also already help if getGroupingValue would receive the index to the original row, so one can call the same accessor with these params (Because at this point the limitation might exist because the row models do not exist yet)

[MILLERMARRU]

This is already addressed in the upcoming v9, currently in beta, worth checking before building a workaround on top of v8.

Comparing the source directly: on the current stable v8.21.3, ColumnGrouping.ts types getGroupingValue as (row: TData) => any, a single argument, exactly the limitation described here. On the v9 beta branch, columnGroupingFeature.types.ts has already changed the signature to (originalRow: TData, index: number, row: Row<TFeatures, TData>) => any, and row_getGroupingValue in columnGroupingFeature.utils.ts calls it as column.columnDef.getGroupingValue(row.original, row.index, row), so both the index and the full row (with all its own methods) are already there.

For v8 in the meantime, since row.index isn't accessible from inside getGroupingValue, one workaround is precomputing an index lookup keyed by object identity before handing data to the table, assuming the row objects themselves are referentially stable across renders:

const indexByRef = new WeakMap(data.map((row, i) => [row, i]))

// in the columnDef:
getGroupingValue: (originalRow) => {
  const index = indexByRef.get(originalRow)
  return computeGroupKey(originalRow, index)
}

That only holds if data isn't being recreated with new object references between renders (a common enough assumption for TanStack Table setups already memoizing data, but worth double-checking). Otherwise, trying the v9 beta directly and using the three-argument signature is the more direct route, since this exact gap is what's being closed there.

[dvmoritzschoefl]

Thanks we are already using the beta and this fix. I can close this discussion

[MILLERMARRU]

I'm happy to help. Before closing the discussion, it would help me a lot if you accepted the answer as resolved.