fix(router-core): preserve element scroll restoration in scrollToTopSelectors#7704
fix(router-core): preserve element scroll restoration in scrollToTopSelectors#7704EduardF1 wants to merge 1 commit into
Conversation
…electors When an element is both a scroll-restoration target and listed in `scrollToTopSelectors`, the scroll-to-top fallback in `onRendered` ran after the element was restored and reset it back to 0. The fallback was only suppressed for the window (via `windowRestored`), not for elements. Track successfully restored elements in a `restoredElements` set and skip them in the scroll-to-top fallback loop, mirroring the existing `windowRestored` guard. Adds a regression test that fails without the fix. Closes TanStack#7687 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughScroll restoration now tracks restored non-window elements during ChangesElement scroll restoration fix
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Summary
Fixes #7687.
When a scroll container element is both a scroll-restoration target and listed in
scrollToTopSelectors, its restored scroll position was immediately reset to0.In the
onRenderedhandler ofsetupScrollRestorationthe scroll-to-top fallback was only suppressed for the window (via thewindowRestoredflag). After an element was successfully restored (element.scrollTop = scrollY), the fallback loop still ranelement.scrollTo({ top: 0 })on that same element, wiping the just-restored position.Fix
Track successfully restored elements in a
restoredElementsset andcontinuepast them in the scroll-to-top fallback loop — mirroring exactly howwindowRestoredalready guards the window. Minimal and surgical: no behavior change for elements that are only inscrollToTopSelectors(and were not restored), which are still scrolled to top as before.Validation
packages/router-core/tests/scroll-restoration.test.tsthat drivesonBeforeLoad+onRenderedwith an element that is both restored and present inscrollToTopSelectors. It asserts the restoredscrollTop(100) survives.expected +0 to be 100) and passes with it.vitest runfor@tanstack/router-core: 1179 passed, 3 expected-fail (pre-existing), 0 type errors (39 files).eslinton both changed files: clean.Not a duplicate
No open PR addresses #7687. Related open scroll PRs target different concerns: #7332 (hash precedence), #7335 (carrying nested positions across new restoration keys), #7574 (docs), #4059 (feature to disable restoration). This fixes the fallback-vs-restore ordering for elements specifically.
Summary by CodeRabbit