Next.js Discord

Discord Forum

Why does loading.tsx get triggered when navigating *away* from a route?

Unanswered
Pharaoh Hound posted this in #help-forum
Open in Discord
Pharaoh HoundOP
I have a simple server component:

export default async function Page() {
  // wait for 5 seconds

  await new Promise((resolve) => setTimeout(resolve, 5000));

  return <Link href={'/other-page'}> hello world</Link>;
}


and in the same folder I have loading.tsx which shows a loading skeleton. But the loading.tsx only renders when I click on the link. How does this make sense? What is happening here?

13 Replies

Pharaoh HoundOP
Oddly enough, everything works as expected if I manually set a Suspense boundary, so this feels like something broken in how Next is automatically setting up my Suspense boundaries?
@Pharaoh Hound
Suspense only works on navigating through pages
refreshing the page with a browser refresh wont work
we think its gonna be improved upon when ppr is released by vercel, but nobody is sure atm.
Pharaoh HoundOP
@Arinji I think you're misunderstanding what I'm saying:

I have route A and route B both with a loading.tsx. When I land on route A (i.e. the page has fully loaded) and click a link to route B, I see route A's loading.tsx quickly before being navigated to route B and seeing its loading.tsx. I'm essentially seeing both loading.tsx's which doesn't make any sense. I've seen a number of people experiencing weird behavior like this so it seems like a bug in NextJS...
Pharaoh HoundOP
just created a new next app with nothing except a repro. Will upload to stackblitz or something in a sec
you can notice it easier if you let the root route fully load, then throttle your network
I noticed two bugs while creating this though:

1: landing on / and then clicking a link to a dynamic url /test/[id] will render both / and /test/[id]'s loading.tsx
2. if you have a route like this: /, /test, /test/[id], going from / to /test/[id] will render /test and /test/[id]'s loading.tsx
My guess is there's a bug in NextJS that's related the logic of figuring out which loading.tsx to render as a fallback, since the behavior seems different depending on how you configure your routes