fix(table-core): don't fire onExpandedChange when resetExpanded is a no-op

[Faithfinder]

table_resetExpanded builds a fresh state object and always calls onExpandedChange, without comparing against the current state. Every sibling compares first:

• table_resetPageIndex / table_resetPageSize — early-return when the value already matches
• row_toggleExpanded / table_toggleAllRowsExpanded — early-return, added in fix(table-core): correct expanded/paginated state contents and sorting toggle defaults #6501
• table_resetExpanded — no guard

Since #6499 wired the expansion auto-reset into createCoreRowModel, that unguarded write fires on every data reference change:

data identity changes → core row model recomputes → table_autoResetExpanded → table_resetExpanded → onExpandedChange(newEmptyMap) → consumer re-renders → new data reference → repeat.

Measured with this repo's react-table on React 19.2, controlled expanded via useState, getRowCanExpand: () => true, and one row-model read during render, capped at 50 renders:

data	renders	onExpandedChange calls
items ?? []	50 (capped)	48
items ?? [] + this fix	2	0
items ?? STABLE_EMPTY_ARRAY	2	0
items ?? [] + autoResetExpanded: false	2	0

Stable data is documented, and the loop needs an unstable reference — this is a user mistake in the first instance. The case for guarding anyway is that the punishment is disproportionate and near-undiagnosable: nothing in the stack points at expansion, and the tab is too unresponsive to profile. The pagination resets already absorb exactly this mistake, and v8 absorbed it too — it passed table.initialState?.expanded through by reference, so setExpanded(sameRef) hit the identity check in useState. v9 clones it, so the reference is always new.

Change

table_resetExpanded compares its target against table.atoms.expanded?.get() (as row_toggleExpanded already does) and returns early when they match — true by identity, maps key-by-key, both defaultState branches.

Two existing tests asserted that the reset fires when the current state already equals the target. They now diverge the state first, so they still cover the reset value.

Summary by CodeRabbit

• Bug Fixes

  • Prevented redundant expanded-state updates when resetting a table whose expanded state is already synchronized.
  • Avoided unnecessary change callbacks and potential render loops when data references change.
  • Preserved correct reset behavior when expanded rows differ.

• Documentation

  • Updated expansion API source links and documented the no-op reset behavior.

• Tests

  • Added coverage for synchronized resets, changed expanded-row states, and controlled-state reset scenarios.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 467f5e78-23be-46a7-a3b3-c63eea574de9

📥 Commits

Reviewing files that changed from the base of the PR and between 59e8367 and 9d4099a.

📒 Files selected for processing (16)

• docs/reference/static-functions/functions/getDefaultExpandedState.md
• docs/reference/static-functions/functions/row_getCanExpand.md
• docs/reference/static-functions/functions/row_getIsAllParentsExpanded.md
• docs/reference/static-functions/functions/row_getIsExpanded.md
• docs/reference/static-functions/functions/row_getToggleExpandedHandler.md
• docs/reference/static-functions/functions/row_toggleExpanded.md
• docs/reference/static-functions/functions/table_autoResetExpanded.md
• docs/reference/static-functions/functions/table_getCanSomeRowsExpand.md
• docs/reference/static-functions/functions/table_getExpandedDepth.md
• docs/reference/static-functions/functions/table_getIsAllRowsExpanded.md
• docs/reference/static-functions/functions/table_getIsSomeRowsExpanded.md
• docs/reference/static-functions/functions/table_getToggleAllRowsExpandedHandler.md
• docs/reference/static-functions/functions/table_resetExpanded.md
• docs/reference/static-functions/functions/table_setExpanded.md
• docs/reference/static-functions/functions/table_toggleAllRowsExpanded.md
• packages/table-core/src/features/row-expanding/rowExpandingFeature.utils.ts

🚧 Files skipped from review as they are similar to previous changes (12)

• docs/reference/static-functions/functions/row_getIsExpanded.md
• docs/reference/static-functions/functions/table_getIsAllRowsExpanded.md
• docs/reference/static-functions/functions/table_getToggleAllRowsExpandedHandler.md
• docs/reference/static-functions/functions/row_getCanExpand.md
• docs/reference/static-functions/functions/table_getExpandedDepth.md
• docs/reference/static-functions/functions/table_getCanSomeRowsExpand.md
• docs/reference/static-functions/functions/row_getToggleExpandedHandler.md
• docs/reference/static-functions/functions/row_getIsAllParentsExpanded.md
• docs/reference/static-functions/functions/row_toggleExpanded.md
• docs/reference/static-functions/functions/table_getIsSomeRowsExpanded.md
• docs/reference/static-functions/functions/table_resetExpanded.md
• packages/table-core/src/features/row-expanding/rowExpandingFeature.utils.ts

---

📝 Walkthrough

Walkthrough

table_resetExpanded now skips onExpandedChange when the computed reset state equals the current expanded state. Tests cover reset variants and controlled auto-reset behavior. Documentation links and reset behavior descriptions were updated.

Changes

Expanded reset behavior

Layer / File(s)	Summary
Reset equality guard and references packages/table-core/src/features/row-expanding/rowExpandingFeature.utils.ts, docs/reference/static-functions/functions/*, .changeset/reset-expanded-noop.md	table_resetExpanded compares expanded states before publishing changes. Documentation links and reset behavior details were updated.
Reset and controlled-state regression coverage packages/table-core/tests/unit/features/row-expanding/rowExpandingFeature.utils.test.ts	Tests cover differing and matching expanded states, expanded-all resets, default resets, and controlled auto-reset after data identity changes.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• TanStack/table#6499: Both changes modify expansion auto-reset behavior.
• TanStack/table#6501: Both changes prevent redundant expansion state updates or callbacks.

Suggested reviewers: kevinvandy

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the primary fix to avoid firing onExpandedChange for no-op resetExpanded calls.
Description check	✅ Passed	The description clearly explains the problem, motivation, implementation, regression scenario, test results, and changeset impact.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[KevinVandy]

we already have code for shallow checking in tanstack store. I might look into more broadly applying that in our setState functions instead of re-implementing shallow checks throughout the entire codebase like this.

[Faithfinder]

we already have code for shallow checking in tanstack store. I might look into more broadly applying that in our setState functions instead of re-implementing shallow checks throughout the entire codebase like this.

Swapped to existing shallow compare function.

As for moving it to setState, I'll defer that to you. One thing my bot highlighted about that is this:

table_setExpanded takes an Updater, not a value, so we'd have to resolve the updater first to know whether to call onExpandedChange. table_setPagination's safeUpdater doesn't really help here because it only resolves inside the consumer's setState. Resolving it earlier would also trigger row_toggleExpanded's expanded-all materialization even if the consumer never ends up applying the update. If you do move the guard down to that layer, this change just becomes a two-line deletion.

[MILLERMARRU]

Went and checked shallow() in @tanstack/store directly since the whole fix hinges on it comparing the two ExpandedState values correctly. It does Object.is first, then falls through to a key-by-key comparison for plain objects, and bails to false if the types don't match (so true vs {} correctly comes out unequal). Since ExpandedState here is always either true or a plain Record<string, boolean> built through makeObjectMap, that comparison path is exactly the right one, no Map/Set/Date branch needed.

This also brings table_resetExpanded in line with row.toggleExpanded and table.toggleAllRowsExpanded, which already skip firing the change handler on a no-op, so it's fixing an actual inconsistency rather than adding new behavior.

The regression test at the bottom (should not loop when a data identity change resets controlled state that already matches) is the one that sells the fix for me. It reproduces the real scenario from the changeset, core row model auto-resetting expanded on every data identity change, feeding back into a controlled table that never converges, and it caps onExpandedChange calls at 5 so a regression fails loudly instead of hanging the suite. That's exactly the kind of test I'd want to see before trusting a "stop an infinite loop" fix.

should reset when the expanded ids differ at the same count is also a good addition on its own, it rules out a lazy same-length-means-equal shortcut, which shallow doesn't take anyway but is worth locking in with a test.

Nothing here looks wrong to me, the fallback to {} on table.atoms.expanded?.get() ?? {} is safe since expanded state is never false or null by type, just true or a map.

[KevinVandy]

closed in favor of #6532