Repository navigation
cause uses cached match in beforeLoad and loader functions #3179
Description
Which project does this relate to?
Router
Describe the bug
Hovering a link while preloading is enabled for the router, will cause the loader to run with the cached cause value from the last the the route loader was cached.
If you refer to my reproduction, when loading to the / route and refer to the console logs, we can see that cause is always enter every time the "home" link is hovered. If we loaded the page on /about it is first preload and then correctly updates to enter when visiting /, but once on the page, and continuing to hover the home button, the cause remains as enter instead of stay.
Notice I have the version of the router set to 1.87.0. This looks to work find in 1.86.0 but all newer versions (tested all minor versions from 1.87 -> 1.97.1` with the same issue).
If I had to make an educated guess at what introduced this, I'd say commit 941ff2d probably had something to do with it, specifically line 2855 where we are no longer updating currently matched matches (which presumably causes cause to no longer get updated with "stay" because it's being skipped under that condition).
Not sure on a simple fix for this one since I am sure removing this condition will probably break existing features.
Thanks in advance
Your Example Website or App
Steps to Reproduce the Bug or Issue
- Go to Home (
/) - Hover the Home button
- Observe the console printing
cause: enterinstead ofcause: stay
Expected behavior
- Go to Home (
/) - Hover the Home button
- Observe the console printing
cause: stay
Screenshots or Videos
Platform
- OS: Windows 11
- Browser: Arc
- Version: 1.87.0 -> 1.97.1
Additional context
Noticed this since our application has some redux actions in our loader that should only run when navigating to the page for the first time, however after upgrading, would cause them to run every time someone hovered a link on the page, which would also show a full page loader (and if the mouse was not moved from where the link would re-render after the loader, this would repeat indefinitely)
Activity
ViewableGravy commentedon Mar 2, 2025
Just tested this one again with 1.112.0 and it still looks to be happening.
I also noticed when re-testing on either version, that if you go from about to home, hovering has the cause "enter", but if you are already on the home route, click the button and then hover, it correctly updates. It seems to be only the case that cause doesn't update, when you are coming from another page, because the pre-fetch is preventing it from updating
danivideda commentedon Jun 9, 2026
Bumping this because the issue still persists in version 1.170.10, the current latest version.
The loader still runs with
cause: enterwhen it's just being hovered. Only after I press the link again does it correctly update thecause: stayand the hover doesn't trigger the loader function anymore.lpic10 commentedon Jun 9, 2026
Also
preloadseems to always befalsewhen hovering the links.I noticed this issue when trying to avoid running some auth checks on
beforeLoadduringpreloadI don't find a consistent way to know if the route is actually being preloaded.
danivideda commentedon Jun 9, 2026
Perhaps the
defaultPreloadis set tofalsein yourcreateRouter, or in the<Link>props itself? Because if that’s the case, I don’t think it’s related to this issue threadlpic10 commentedon Jun 9, 2026
I have it set to 'intent' but you are right, it is not related to this thread.
After testing I see that it correctly set preload to true in the attached stackblitz when in the About page and hovering Home. Maybe the issue I have is because I set the
beforeLoadin a layout page down the hierarchy, so maybe that cause other links in the same layout page to receivepreload: false. I will open a separated issue if I can reproduce with a small example.danivideda commentedon Jun 16, 2026
@schiller-manuel is this an expected behavior for the
loaderto run on hover<Link>withcause: enterand notcause: preload?test: pin 24 community-reported issues fixed by the match-loading wor…
danivideda commentedon Aug 5, 2026
Thank you
chore: update TanStack Router package to v1.70.19 that fixes my issue…