I don't understand parallel routes
Answered
Manx posted this in #help-forum
ManxOP
I tried understanding them, but it looks like doing normal components inter-importing but in an unnecessarily complex way.
For instance, instead of importing one component A1a inside a component A1 inside a page/route A, I have to do that plus adding "default.tsx" to all other components B1, C1, D1, etc.
It visually organizes the code, tho this is not a feature that can't be achieved with normal components.
I'm so noob at this, so I might lack a lot of information, please correct me if I'm wrong.
For instance, instead of importing one component A1a inside a component A1 inside a page/route A, I have to do that plus adding "default.tsx" to all other components B1, C1, D1, etc.
It visually organizes the code, tho this is not a feature that can't be achieved with normal components.
I'm so noob at this, so I might lack a lot of information, please correct me if I'm wrong.
Answered by joulev
parallel route is not a required feature of nextjs that you must use in all apps. it's a niche feature that is only needed when it is needed – when you need it you will know because you will discover that it's really hard if not impossible to build without it.
take this for example: https://joulev.sell.app. the content and the banner depend on the current page, so they must be in page.tsx files. meanwhile the navbar is at the middle of them so you cannot put both the banner and the main page content into a single
now you might say, what if i simply import the navbar into the page? no that won't work because then the navbar would be remounted on page change which will mess with UI, animation and whatnot. not to mention in SSR the navbar would be recomputed every page change which is far from optimal.
you might also say, what if i load the banner of all pages and display them on the client based on
parallel routes is a niche feature, you don't have to use it. and you will know you need it when you find yourself in a use case that needs this feature. to remember parallel routes you just need to know it's just the feature where you can split a
take this for example: https://joulev.sell.app. the content and the banner depend on the current page, so they must be in page.tsx files. meanwhile the navbar is at the middle of them so you cannot put both the banner and the main page content into a single
{children} prop, you need to do thing likefunction Layout({ banner, children }) {
return (
<div>
{banner}
<Navbar />
{children}
</div>
);
}now you might say, what if i simply import the navbar into the page? no that won't work because then the navbar would be remounted on page change which will mess with UI, animation and whatnot. not to mention in SSR the navbar would be recomputed every page change which is far from optimal.
you might also say, what if i load the banner of all pages and display them on the client based on
usePathname? it might work depending on the use case, but if the banner is server side rendered based on an external data source, that will once again be suboptimal at best.parallel routes is a niche feature, you don't have to use it. and you will know you need it when you find yourself in a use case that needs this feature. to remember parallel routes you just need to know it's just the feature where you can split a
page.tsx file into several parts instead of one big chunk thrown into the children prop in the layout.9 Replies
ManxOP
Oh! I love that I can dynamically "import" components with parallel routes, tho.
@Manx I tried understanding them, but it looks like doing normal components inter-importing but in an unnecessarily complex way.
For instance, instead of importing one component A1a inside a component A1 inside a page/route A, I have to do that plus adding "default.tsx" to all other components B1, C1, D1, etc.
It visually organizes the code, tho this is not a feature that can't be achieved with normal components.
I'm so noob at this, so I might lack a lot of information, please correct me if I'm wrong.
parallel routes is for when you need to split the page into several different parts to put into disjointed slots in the layout.
consider the case in this screenshot, you want the red part to be page-specific (and will change when you navigate to a different page), but the blue part to be in the layout (and should not be remounted/recalculated when you navigate). it's very very hard to structure your html in a way that the two red rectangles can be put inside one single slot
consider the case in this screenshot, you want the red part to be page-specific (and will change when you navigate to a different page), but the blue part to be in the layout (and should not be remounted/recalculated when you navigate). it's very very hard to structure your html in a way that the two red rectangles can be put inside one single slot
children. chances are each red rectangle needs a slot of its own.https://app-router.vercel.app/parallel-routes this example might help
@joulev parallel routes is for when you need to split the page into several different parts to put into disjointed slots in the layout.
consider the case in this screenshot, you want the red part to be page-specific (and will change when you navigate to a different page), but the blue part to be in the layout (and should not be remounted/recalculated when you navigate). it's very very hard to structure your html in a way that the two red rectangles can be put inside one single slot `children`. chances are each red rectangle needs a slot of its own.
ManxOP
If I understand correctly, you have "one" page split into two components, and each component is rendered inside a different part of the layout?
Then it's not really one page, those are just two components, IDK how the exact code will be in terms of the example you've provided but I assume it would be:
- PR (parallel route) one with part 1 of the page
- PR two with part 2 of the page
- both PRs inside one layout
I don't see how this would be helpful in the real world, I've seen one real world example on YT, but it was a simple gallery which when you click on an image "page", it pops up while still inside the same context/layout, but the url changes for shareability. But I've seen Google doing the same thing practically without such a complex mechanism, by using simple "share" and "visit" buttons.
Then it's not really one page, those are just two components, IDK how the exact code will be in terms of the example you've provided but I assume it would be:
- PR (parallel route) one with part 1 of the page
- PR two with part 2 of the page
- both PRs inside one layout
I don't see how this would be helpful in the real world, I've seen one real world example on YT, but it was a simple gallery which when you click on an image "page", it pops up while still inside the same context/layout, but the url changes for shareability. But I've seen Google doing the same thing practically without such a complex mechanism, by using simple "share" and "visit" buttons.
@iyxan23 https://app-router.vercel.app/parallel-routes this example might help
ManxOP
This example is really good, tho it didn't help me understand it that much, I've seen similar example on YT as well. I just need to understand what can parallel routes do that can't be done otherwise using components, etc.
@Manx If I understand correctly, you have "one" page split into two components, and each component is rendered inside a different part of the layout?
Then it's not really one page, those are just two components, IDK how the exact code will be in terms of the example you've provided but I assume it would be:
- PR (parallel route) one with part 1 of the page
- PR two with part 2 of the page
- both PRs inside one layout
I don't see how this would be helpful in the real world, I've seen one real world example on YT, but it was a simple gallery which when you click on an image "page", it pops up while still inside the same context/layout, but the url changes for shareability. But I've seen Google doing the same thing practically without such a complex mechanism, by using simple "share" and "visit" buttons.
parallel route is not a required feature of nextjs that you must use in all apps. it's a niche feature that is only needed when it is needed – when you need it you will know because you will discover that it's really hard if not impossible to build without it.
take this for example: https://joulev.sell.app. the content and the banner depend on the current page, so they must be in page.tsx files. meanwhile the navbar is at the middle of them so you cannot put both the banner and the main page content into a single
now you might say, what if i simply import the navbar into the page? no that won't work because then the navbar would be remounted on page change which will mess with UI, animation and whatnot. not to mention in SSR the navbar would be recomputed every page change which is far from optimal.
you might also say, what if i load the banner of all pages and display them on the client based on
parallel routes is a niche feature, you don't have to use it. and you will know you need it when you find yourself in a use case that needs this feature. to remember parallel routes you just need to know it's just the feature where you can split a
take this for example: https://joulev.sell.app. the content and the banner depend on the current page, so they must be in page.tsx files. meanwhile the navbar is at the middle of them so you cannot put both the banner and the main page content into a single
{children} prop, you need to do thing likefunction Layout({ banner, children }) {
return (
<div>
{banner}
<Navbar />
{children}
</div>
);
}now you might say, what if i simply import the navbar into the page? no that won't work because then the navbar would be remounted on page change which will mess with UI, animation and whatnot. not to mention in SSR the navbar would be recomputed every page change which is far from optimal.
you might also say, what if i load the banner of all pages and display them on the client based on
usePathname? it might work depending on the use case, but if the banner is server side rendered based on an external data source, that will once again be suboptimal at best.parallel routes is a niche feature, you don't have to use it. and you will know you need it when you find yourself in a use case that needs this feature. to remember parallel routes you just need to know it's just the feature where you can split a
page.tsx file into several parts instead of one big chunk thrown into the children prop in the layout.Answer
@joulev parallel route is not a required feature of nextjs that you must use in all apps. it's a niche feature that is only needed when it is needed – when you need it you will know because you will discover that it's really hard if not impossible to build without it.
take this for example: https://joulev.sell.app. the content and the banner depend on the current page, so they must be in page.tsx files. meanwhile the navbar is at the middle of them so you cannot put both the banner and the main page content into a single `{children}` prop, you need to do thing like
tsx
function Layout({ banner, children }) {
return (
<div>
{banner}
<Navbar />
{children}
</div>
);
}
now you might say, what if i simply import the navbar into the page? no that won't work because then the navbar would be remounted on page change which will mess with UI, animation and whatnot. not to mention in SSR the navbar would be recomputed every page change which is far from optimal.
you might also say, what if i load the banner of all pages and display them on the client based on `usePathname`? it might work depending on the use case, but if the banner is server side rendered based on an external data source, that will once again be suboptimal at best.
parallel routes is a niche feature, you don't have to use it. and you will know you need it when you find yourself in a use case that needs this feature. to remember parallel routes you just need to know it's just the feature where you can split a `page.tsx` file into several parts instead of one big chunk thrown into the `children` prop in the layout.
ManxOP
🤯 I just understood the problem that it solves, it toke me a while to wrap my head around it, it's a cool feature. You're right: I don't see myself using such an advanced feature, but definitely good to have in my arsenal.
If I understood this correctly, the page also could've been able to export more than one component with the default being imported to the layout as
Thank you for the precious efforts.
If I understood this correctly, the page also could've been able to export more than one component with the default being imported to the layout as
children and the exported named components would've been imported as e.g: banner (not judging the decision makers as I don't really understand the internals).Thank you for the precious efforts.
@Manx 🤯 I just understood the problem that it solves, it toke me a while to wrap my head around it, it's a cool feature. You're right: I don't see myself using such an advanced feature, but definitely good to have in my arsenal.
If I understood this correctly, the page also could've been able to export more than one component with the default being imported to the layout as `children` and the exported named components would've been imported as e.g: `banner` (not judging the decision makers as I don't really understand the internals).
Thank you for the precious efforts.
Yup, they could have decided to use named exports and it would work similarly. Think of it like slots in vue or svelte if you have used those libraries.
Though by using files it allows you to build more complex patterns (at the cost of more files to manage), like
where the main children page.tsx files are normal route files (like “about”), while the parallel route files are managed by a catch-all dynamic route. Not 100% sure if this actually works, but the file system convention allows this kind of thing to be possible.
Though by using files it allows you to build more complex patterns (at the cost of more files to manage), like
app/
@banner/
[[…slug]]/
page.tsx
about/
page.tsx
layout.tsx
page.tsxwhere the main children page.tsx files are normal route files (like “about”), while the parallel route files are managed by a catch-all dynamic route. Not 100% sure if this actually works, but the file system convention allows this kind of thing to be possible.