[NEXT-1144] Parallel Routes do not apply individual loading.tsx as described in documentation

[brunocangs]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.19.1
      npm: 8.19.3
      Yarn: 1.22.19
      pnpm: 7.3.0
    Relevant packages:
      next: 13.3.5-canary.12
      eslint-config-next: 13.4.0
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Routing (next/router, next/navigation, next/link)

Link to the code that reproduces this issue

/~https://github.com/brunocangs/next-app-parallel-issue

To Reproduce

Run the project with yarn dev and navigate to http://localhost:3000

Describe the Bug

When using Parallel Routes (e.g. /app/@slot/page.tsx), the @slot's loading.tsx states are never called or displayed.

The current beahviours observed even differ in dev and prod, as seen in the videos references.

Prod Link: https://next-app-parallel-issue.vercel.app/

Dev behaviour:

• Layout displays:
  • First slot (@slot/page.tsx) is async, so it displays a loading state. However this is the page's loading state, not the slot loading state.
  • Second slot is not async, so it immediately displays. The Suspended component displays it's loading state correctly
• Suspended component on second slots loads
• Eventually First slot loads and displays it's suspended component correctly.
• Suspended component on first slot loads

Untitled.mov

Prod behaviour:

• Everything gets server loaded and awaited. The parts that would require basic suspending get optimized and no loading states are displayed.

I didn't include a prod video as it would only be a page reload

Expected Behavior

It is expected that, as mentioned in the documentation, the loading state for each of the slots will be correctly displayed per the image below

Which browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

Vercel

_NEXT-1144

[satarovbekzhan]

Same for me!

[zanzlender]

+1

But wrapping each individual component inside the layout with suspense works as expected.

[luisorbaiceta]

Yes. In this case the documentation is not describing the current behavior and is misleading. The loading and error components are being applied as follows:

Seems that the root loading and error components are applied separately to each parallel route. This is inconvenient as precisely the goal of parallel routing is being able to manage separate parts of the UI that are not related with each other at the same time.

[satarovbekzhan]

Any updates @timneutkens?

[timneutkens]

You can temporarily put it in a route group app/@something/(myroutegroup)/loading.tsx.

[tomsseisums]

It seems that error.tsx is also affected?

[tomsseisums]

And @timneutkens the route group doesn't work for me on v13.4.2, for neither, both loading.tsx and error.tsx seem to be ignored.

[armandsalle]

+1

But wrapping each individual component inside the layout with suspense works as expected.

This works for me but the loading state is only display at the initial load, when I revalidate the path or call router.refresh(), the loading state is not showing.

[zanzlender]

Can confirm... But isn't this supposed to work like this? It just hidrates the component with the new data?

bandicam.2023-05-22.11-46-49-540.mp4

[josias-r]

#50107 (comment) loading and error.tsx

[tresorama]

Related:

• How to use `error` and `loading` in parallel routes in "app" dir ? #49588
• loading/error.tsx ignored for parallel routes #50107

[cprussin]

FWIW in my testing using a default state (i.e. default.jsx) in a parallel route also doesn't trigger a loading state, even with the temporary route group fix that @timneutkens suggested.

[run4w4y]

Having the same issue with default.tsx unfortunately :(
Putting the loading.tsx in a route group did not help either, guess I'll just use my own Suspense in the layout until it gets fixed

[danielvanc]

Hey @timneutkens, could we have an estimate of timeline on this feature, please?

It shouldn't be in the docs if you can't currently do what the docs are demonstrating (without resorting to a work around).

[Jon1VK]

Also the layout file inside a parallel route is ignored. For example /@team/layout.tsx will not be rendered. With /@team/(__workaround)/layout.tsx it works currently, but it is not optimal to use such hacks.

[jvanmaaren]

FYI the route group hack doesn't seem to work in combination with a default.tsx:
#48090

edit: The route group hack isn't needed anymore 👍

[TommySorensen]

I'm not sure its fixed since i haven't had time to check. But they fixed some issues lately #51413

[caturbgs]

I think it's finally getting fixed, my current code that using React.Suspense is getting overwritten using loading component loading.tsx on the recent version 13.4.7.

[danielvanc]

I can confirm that #51413 has fixed these issues. 🥳

[tresorama]

It's fixed with 13.4.7 for me too
codesandbox demo

[run4w4y]

Cannot confirm that it works for me on 13.4.7 with default.tsx present :(
So I don't think the issue is completely resolved unfortunately

[MaKTaiL]

I'm having the same issue but with layout.tsx. I had to apply the solution on #49243 (comment) of creating a (group) inside each of the parallel routes so that the nested layouts could finally work:

/home
├── @dashboard
│   └── (dashboard)
│        ├── layout.tsx
│        └── page.tsx
├── @login
│   └── (login)
│        ├── layout.tsx
│        └── page.tsx
└─ layout.tsx

[hckhanh]

In my case, only production build is affected. I can run correctly in dev mode. Next version: 13.4.19. I also tried canary version: 13.4.20-canary.15

[Sh031224]

/home
├── @foo 
│        ├── layout.tsx
│        ├── loading.tsx
│        └── page.tsx
├── @bar
│        ├── layout.tsx
│        ├── loading.tsx
│        └── page.tsx
└─ layout.tsx

For me the layout and loading are strange only on production builds either.

next version: 13.4.20-canary.6

Demo is here
Port 3000 is production build, and port 3001 is development mode.

Production:
/~https://github.com/vercel/next.js/assets/51149996/d0d747c2-68a1-4922-9f79-6a0172362b32

Development:
/~https://github.com/vercel/next.js/assets/51149996/a1f11c65-ecb1-4a96-8645-e37e6f9b1e3d

loading.tsx shows 'loading...' and layout.tsx changes background color.

[NCSmit]

Still encountering this error on v13.5^
This routing method works correctly in 13.4.7 but it seems the bug has re-appeared in 13.5^.

Hoping for a fix soon :(

[Shameekh-Naveed]

Still encountering on v13.5.2

[jonatassales]

Still on v14.0.3. This would supposed to be a crucial feature, right?

[NCSmit]

@Shameekh-Naveed @jonatassales
Hey guys, mind sharing your folder structures or code? Perhaps I am able to help resolve the issues you're encountering!

[ztanner]

Hi all -- the original reproduction in this thread seems to be behaving correctly (testing against the latest Next.js canary).

For those commenting on the loading state not appearing in production builds: the examples that have been shared indicate that your pages can be statically generated (learn more about dynamic rendering here). In other words, at build time, Next.js is prefetching your routes and generating static HTML. Once served to the user, since the page could be completely statically generated, there's no need to rendering a loading boundary as there's nothing to wait for.

If anyone is still running into problems here, please open a new issue with a minimal reproduction and we'll take a look. As the original reproduction shared in this issue is now working, I'm going to close this.

[Jon1VK]

@ztanner What about a situation where a site has static dynamic routes and not all of the dynamic routes are prerendered on build time. Let's say we have a dynamic route /[page] and only routes /1 and /2 were generated on build. Now when the first user navigates to /3, they have to wait for the whole page to be generated without any shown loading states.

In my opinion the loading states should be also rendered in that situation but now the UI is just stuck waiting for the whole page generation to be finished and sent to the client after which the site navigates to the page. It is quite horrible UX for the first user that tries to navigate to a page which is static but was not generated on build time.

[jainmohit2001]

Hi @ztanner.
I have the same problem listed in this GitHub issue #59463. I have created a vercel deployment as well for the same.

[MohammadElokour]

I'm on next 14.0.0, and the "layout.tsx" also sometimes doesn't work.

I have multiple parallel routes all with "page.tsx" and "layout.tsx" and one of these routes out of all of them wont render the "layout.tsx" (definitely a head scratcher), my use case is mainly to have a parent layout with multiple children as appose to giving each parallel layout separate "error.tsx" and "loading.tsx"

I ended up using the same route group hack as suggested above to solve the issue, here is my folder structure as of now:

Also oddly the main two parallel routes are loading separately (a behavior I'm not quite fond of) even though I haven't added any loading.tsx to each of them, I guess they are individually using the loading.tsx of their parent so I might just remove it?

[fiasco]

I have the same issue with 13.5.6.

As a work around, I was able to remove the parallel route and replace it with a Suspense wrapper in layout.tsx

    <Suspense fallback={<LoadingHeader />}>
      <Header params={params} />
    </Suspense>

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.