RootRoute pendingComponent after "lane match loader rewrite" always visible

[codeart1st]

Which project does this relate to?

Router

Describe the bug

Before the latest "lane match loader rewrite" the pendingComponent from the RootRoute was only visible in the first load of the SPA. It was not visible during route transitions after the initial application load.
After the rewrite it's not possible anymore to have a initial pendingComponent, but not use it afterwards.

Complete minimal reproducer

https://stackblitz.com/edit/github-s5suhk5r-9udezxgo?file=src%2Froutes%2F__root.tsx

Steps to Reproduce the Bug

1. The blue pendingComponent from index.html is shown
2. The blue RootRoute pendingComponent is shown
3. The start page is shown
4. Navigating to the "About" page
5. The RootRoute pendingComponent is shown again

Expected behavior

The pendingComponent of the RootRoute is shown only once during initial SPA load.

Screenshots or Videos

No response

Platform

• Router / Start Version: @tanstack/react-router@1.170.19

Additional context

No response

[Sheraff]

out of curiosity, why do you expect it to behave differently on 1st load vs subsequent navigations? Why is that the desired behavior?

[codeart1st]

Fair point. The primary goal which was achievable with react router and tanstack/router before the latest change was a smooth transition from a placeholder/skeleton UI to the final SPA page.

• adding a basic skeleton UI to the index.html inside the root/main element
• load the react initial bundle
• let react render the Router inside the root/main element
• the root route now renders the same basic skeleton UI as pendingComponent of the RootRoute
• load subsequent lazy code parts and loader data
• replace the basic skeleton UI with the final SPA page

From the user perspective it's like a single jump from a splashscreen to the loaded SPA page. Subsequent page transitions don't need this initial behavior.

If it try to add more pendingComponents to child routes it seems the RootRoute pendingComponent still shown.

Maybe I need another approach for tanstack/router now. In react router the scenario was achievable by using the hydrateFallbackElement.

[suhailopensource]

@Sheraff Agreed the 1st-load vs navigation distinction is arbitrary — framed that way this is a request for something like RR's hydrateFallbackElement, not a regression.

Separable from that: the report also says a child pendingComponent doesn't stop the root's from showing. pendingConfig() picks the boundary by scanning from index 0 for the first non-success match, so an ancestor can win it while only a descendant is loading - the case load-client.ts says it's avoiding ("would hide an already-rendered ancestor while only a descendant is loading"). Is "an already-rendered ancestor shouldn't be replaced by its own fallbac while only a descendant is loading" correct in your model? If so, I'll open a failing test.

@codeart1st — what does the reproducer add on top of the quickstart example? It has no loaders or beforeLoad, so the trigger matters.

[codeart1st]

@codeart1st — what does the reproducer add on top of the quickstart example? It has no loaders or beforeLoad, so the trigger matters.

export const Route = createRootRoute({
 pendingComponent: () => (
 <div style={{ background: 'blue', height: '100vh' }}>Loading...</div>
 ),
 beforeLoad: () => new Promise((resolve) => setTimeout(resolve, 1000)),
 component: RootComponent,
 pendingMs: 0,
});

[codeart1st]

I want to add the information that it's only happening with beforeLoad in the RootRoute not with the loader. A normal loader won't be called again for subsequent route transitions, but beforeLoad runs always and this triggers the pendingComponent from the RootRoute again.

[codeart1st]

#7992 fixes the issue here.

[Sheraff]

#7992 fixes the issue here.

you tested the pkg.pr.new packages and it fixes your issue?

[codeart1st]

#7992 fixes the issue here.

you tested the pkg.pr.new packages and it fixes your issue?

Yes: npm i https://pkg.pr.new/@tanstack/react-router@7992