Problems with Parallel Routes

[cookieMonsterDev]

The Next.js 13.3 brought a new feature that calls the Parallel Routes which allows you to simultaneously or conditionally render one or more pages in the same layout. That is a really cool feature that may reduce the usage of react <Suspense> and improve the logic of data fetching in the app. BUT, I found that there are at least two problems with it and feel to share it

For now, let's take a look at how code looks like without parallel routes. For example for I have a dashboard route that looks like app/projects/page.tsx:

import { Suspense } from "react";

const ProjectsPage = async () => {
  return (
    <div>
      <Suspense fallback={<div>Loading Users...</div>}>
        <Users />
      </Suspense>
      <Suspense fallback={<div>Loading Projects List...</div>}>
        <ProjectsList />
      </Suspense>
    </div>
  );
};

export default ProjectsPage;

const Users = async () => {
  await new Promise((res) => setTimeout(res, 1000));
  return <h1>Users</h1>;
};

const ProjectsList = async () => {
  await new Promise((res) => setTimeout(res, 3000));
  return <h1>Projects</h1>;
};

The code is pretty obvious, we are seeing fallbacks until promises in components are resolved.

Now let's rewrite it using parallel routes. We will create two more folders inside app/projects that will be called @users and @projectslist. Each will contain page.tsx and loading.tsx which are component itself and loading fallback. And also the layout where we can use these components. In general, structure will look like:

   📂 projects
     |
     | --- 📂 @projectslist 
     |        | --- loading.tsx
     |        | --- page.tsx
     |
     | --- 📂 @users
     |        | --- loading.tsx
     |        | --- page.tsx
     |
     | --- layout.tsx
     | --- page.tsx

type LayoutProps = {
  children: React.ReactNode;
  projectslist: React.ReactNode;
  users: React.ReactNode;
};

const Layout = ({ children, users, projectslist }: LayoutProps) => {
  return (
    <div>
      {users}
      {projectslist}
      {children}
    </div>
  );
};

export default Layout;

That works pretty well ha? We have the same logic, do we? Then what are the children in our case? The children is our page.tsx inside the projects folder, and here is the first problem.

First Problem

If we take a look at the original code, we will see that inside the projects page, we have two components however now these components are inside our layout. Soooo, what do I have inside the page since the components are not there? The answer is null!

const ProjectsPage = () => null;

export default ProjectsPage;

The Next.js works so that it requires have page file inside a route to be able to render a page otherwise we receive an error. Sometimes it is annoying to create pages like this, but what to do...

Second Problem

The Parallel Routes can be controlled by nested and dynamic routes it is also a cool feature. But sometimes it is not the best option...
The components from parallel routes live inside root layout for projects route. Let's say we want a page that will be rendered depending on the project id. For this we will create new page with path app/projects/[projectId]/page.tsx. When we try to reach this page we will receive an error. Answer on question why is: Next.js will first try to render the unmatched slot's default.js file. If that's not available, a 404 gets rendered. For us, it means that if we do not want to render these parallel components for our page we need to create new black pages for parallel routes were we return null: app/projects/@projectslist/[projectId]/page.tsx and app/projects/@users/[projectId]/page.tsx:

const Page = () => null;

export default Page;

Just imagine what folder hell awaits you when you have more than 2 parallel routes))

Maybe someone has some suggestions how this behavior can be improved???

[dvzrd]

Wanted to post a similar question/concern about mixing parallel route (slot) layouts with dynamic pages. A use case I have is something like a product details page with a sidebar:

shop/
  [product]
    (details)
      [category] - this page should be the same as the base product details page, just for a diff product category
      @sidebar
        page - sidebar column for product details page
      layout - product details layout has grid with two columns for children (page) and sidebar slot (page in @sidebar)
      page - main column for product details page
    error
    layout - main product page layout (fetch data by id, store in provider, renders header, children, footer, etc)
    loading

Wrapping details inside a (group) dir, the slot layout works inside the nested shop directory. The thing I'm not sure about is how should the dynamic [category] product details page be structured from here?

---

I'm expecting something like this to work, just haven't tried it yet. I think the dynamic [category] page inside the sidebar slot might not work as I expect, but I'm hoping adding a layout file should help. I'll confirm if this is doable and if I find any issues/solutions when I get to this.

[product]
    (details)
      [category]
        page - expect this to render inside the main column of the product (parent) layout's children slot
      @sidebar
        [category]
          page - expect this to render inside the sidebar column of the product (parent) layout's sidebar slot
        page
      layout
      page
    layout

---

Update:

• Seems like the best approach here would be to try using catch all segments - https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes#catch-all-segments
• Intercepting routes could also work: https://nextjs.org/docs/app/building-your-application/routing/intercepting-routes

[ek-kpr]

Were you able to find as solution? I'm trying to attempt something similar to a two pane view.
Left Side should render a list and the right side a view and the routes should be
products/[slug] I was able to make this work with a single slot, but am unable to filter the list based on category pages for example products/books because my list cannot read the params from the current page.

[cookieMonsterDev]

Not, yet.

[maksymlunov]

I also have got a problem, if I use parallel route on path /retro/:id and for others I use default.tsx , after going from /retro/:id to for example /home or /retro I will still have a parallel route rendered for /retro/:id instead of default.tsx as expected.

The way to fix it is wether to create a fallback with null for every page or to refresh the page , the first one looks better but is not cool at all