[nstepien]

TreeDataGrid no longer asks for a function that groups a set of rows into a Record<string, readonly R[]>. Instead, getRowGroupKey(row, columnKey) returns the group key of a single row, and the grid builds the group tree itself.

-  rowGrouper: (rows: readonly R[], columnKey: string) => Record<string, readonly R[]>;
+  getRowGroupKey?: Maybe<(row: R, columnKey: string) => string>;

The new prop is optional. It defaults to String(row[columnKey]), so grouping now only requires groupBy, expandedGroupIds, and onExpandedGroupIdsChange:

 <TreeDataGrid
   groupBy={['country', 'year']}
-  rowGrouper={rowGrouper}
   expandedGroupIds={expandedGroupIds}
   onExpandedGroupIdsChange={setExpandedGroupIds}
 />
-
-function rowGrouper(rows: readonly Row[], columnKey: string) {
-  return Object.groupBy(rows, (row) => row[columnKey]);
-}

Pass it to group on something other than the raw cell value, e.g., bucketing dates by year.

Implementation

• Rows are grouped in a single pass: each row walks the groupBy keys and is added to every group along its path, so a group's childRows holds all of its descendant rows, same as what rowGrouper used to receive at each level. startRowIndex and the total row count are then computed in one pass over the groups.
• isGroupRow is now a module-level function backed by a module-level WeakSet, since group rows are only ever created by TreeDataGrid. It no longer changes when the rows are flattened, so it's out of four dependency arrays.
• React Compiler now compiles TreeDataGrid. On main, it skipped the component because isGroupRow was declared after a return.
• Removed the now-dead GroupBy, GroupByMap, and ReadonlyGroupByMap types, and isReadonlyArray.

As on main, grouping and flattening are separate memos, so expanding or collapsing a group doesn't regroup the rows, and flattening skips collapsed groups. Grouping depends on rows, groupBy, and getRowGroupKey, so the README now also asks to define groupBy outside the component or memoize it, like getRowGroupKey.

Fix for large groups

Expanding a group threw a RangeError when the group had more rows than browsers accept as function arguments, because its rows were added with push(...rows). That's about 124k rows in Chromium, 500k in Firefox, and 638k in WebKit, and the bug is also on main. The rows are now pushed one by one, and a new test expands a group of a million rows and checks that its first row is rendered.

Breaking changes

groupIdGetter is renamed to getGroupId, as function props are moving to getX names.

Groups are now ordered by the first row that belongs to them. Object.entries() previously sorted integer-like group keys numerically, so a numeric group key over unsorted rows will now come out in row order instead of ascending. A new test covers this, and the row grouping demo now sorts its rows by the grouped columns, in order, so its groups stay sorted at every level.

Notes

vp run ci passes. The existing TreeDataGrid tests now run against the default getRowGroupKey, with dedicated tests covering a custom one and the group order. Visual tests were not run locally; test/visual/treeGrid.test.tsx groups rows that are already in order, so the screenshot is expected to be unchanged.

🤖 Generated with Claude Code

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.95%. Comparing base (f1dfede) to head (ec3a181).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4159      +/-   ##
==========================================
+ Coverage   98.58%   98.95%   +0.36%     
==========================================
  Files          46       46              
  Lines        1985     2017      +32     
  Branches      750      787      +37     
==========================================
+ Hits         1957     1996      +39     
+ Misses         28       21       -7     

Files with missing lines	Coverage Δ
src/TreeDataGrid.tsx	98.58% <100.00%> (+4.14%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nstepien]

@amanmahajan7 any issues with replacing rowGrouper with the optional getRowGroupKey prop?
groupIdGetter is also renamed to getGroupId.

I also want to rename rowKeyGetter to getRowKey in a future PR, so this is a precursor to it.

[amanmahajan7]

Is it as flexible as rowGrouper? Is there a case where users may want to have custom grouping logic?

[nstepien]

I think the only "advantage" is that you could control the order of rows in a group with rowGrouper, but I think it's better if we preserve the original row order.

We previously used Object.entries which did not preserve the row order anyway.
See the "Breaking changes" section in the PR description.

We can add a new sortGroupRows prop or other props if we ever need to.

[amanmahajan7]

Asked Claude to check, if you think none of them can be an issue then we can merge it.

For completeness, here's what rowGrouper allowed that getRowGroupKey no longer does, so we have it on record:

Previously possible	Now	Workaround
Custom group order (e.g., groups always A→Z, by count, or by an aggregate, regardless of row order). Object.entries only reordered integer-like keys, so for string keys the order returned by rowGrouper was kept. This also meant a rowGrouper that sorted its keys kept groups in place when rows were sorted with sortColumns.	Groups follow the order of their first row, so sorting rows also reorders groups	Pre-sort rows by the groupBy columns first
Custom order of rows within a group	Rows keep their original order	Sort rows
Excluding rows from grouping	Every row lands in a group	Filter rows first
Groups that depend on other rows (e.g., "Top 3 + Other", price bands based on the data's range). rowGrouper received all the rows of the parent group.	getRowGroupKey only sees one row	Precompute the keys and look them up in getRowGroupKey
Empty groups (e.g., show every month even with no rows). Worked, though an empty group showed as selected because [].every() is true.	A group only exists if a row has its key	None

[nstepien]

Sounds good?

For "empty groups", your Claude found no workaround, but we can implement nested rows with a custom behavior already:
https://comcast.github.io/react-data-grid/#/MasterDetail
https://comcast.github.io/react-data-grid/#/TreeView

We can revisit as needed.

[nstepien]

I'm also considering adding a sort prop on columns, which should simplify a lot of stuff, and resolve some of these concerns.

[amanmahajan7]

I also want to rename rowKeyGetter to getRowGet in a future PR, so this is a precursor to it.

You mean getRowKey?

[nstepien]

You mean getRowKey?

Yes, my bad