How do you build a deeply nested dynamic route like /shop/[category]/[subcategory]/[productId]? What are the pitfalls?

Building a deeply nested dynamic route like /shop/[category]/[subcategory]/[productId] in Next.js involves creating a folder structure that directly maps to the URL segments. In the App Router, you'd create folders at app/shop/[category]/[subcategory]/[productId]/page.tsx. Each folder name in square brackets creates a dynamic segment that becomes a parameter in your component. While this is straightforward to implement, deeply nested routes introduce several pitfalls around data fetching efficiency, error handling, and performance that require careful architectural consideration .

The most significant pitfall with deeply nested routes is the potential for data fetching waterfalls. In the folder structure above, each segment level might have its own data requirements. The layout at shop/[category] might need category metadata, the layout at shop/[category]/[subcategory] might need subcategory data, and the product page needs product data. Without careful design, these fetches happen sequentially: first category, then subcategory (which depends on category), then product (which depends on both). This can add hundreds of milliseconds to page load time . The solution is to lift data fetching: fetch all needed data in the deepest component (the product page) or use parallel data fetching with Promise.all .

For large e-commerce sites, generating all possible product pages with generateStaticParams at the deepest level can lead to extremely long build times. If you have 1000 categories, each with 100 subcategories, each with 1000 products, that's 100 million pages to generate—impossible. The solution is to use a combination of pre-rendering popular paths and on-demand generation with dynamicParams: true or fallback: 'blocking' . For deeply nested routes, you can also generate params at multiple levels: generate all categories at the first level, all subcategories at the second level, but only popular products at the deepest level, letting long-tail content generate on first visit .

In deeply nested routes, an error in fetching category data shouldn't necessarily break the entire page if product data is still available. Without proper error boundaries at each segment level, an error in any parent layout will cause the entire page to fail. The solution is to add error.tsx files at each level of the nesting . This allows graceful degradation: if the category sidebar fails to load, the main product content can still display with appropriate fallback UI. Each level should have its own error.tsx and loading.tsx files to provide progressively granular error recovery .

As routes get deeper, passing params and fetched data down through multiple component levels becomes cumbersome. Server Components can't use React Context, so you either need to fetch data at each level (which may be inefficient) or pass props down through many layers. The solution is to lift data fetching to the deepest component that needs the data, as shown in the parallel fetching example, or use patterns like the Data Access Layer where each component fetches its own data efficiently with caching . For truly shared data, consider using React's cache() function to deduplicate identical requests across components .