In Next.js, a route segment refers to a part of the URL path that corresponds to a specific segment of the file system-based routing structure. Each segment in the URL maps to a folder or file in the app directory (for App Router) or pages directory (for Pages Router).
Create a folder in the app directory. The folder name becomes the route segment.
Use square brackets [] to define a dynamic route segment. app/users/[id]/page.js corresponds to routes like /users/1, /users/2, etc. The id parameter can be accessed in the component.
Use [...slug] to define a catch-all route segment that matches all subsequent segments. app/docs/[...slug]/page.js matches /docs/a, /docs/a/b, /docs/a/b/c, etc. The slug parameter will be an array of the segments.
Use [[...slug]] to define an optional catch-all route segment. app/shop/[[...slug]]/page.js matches /shop, /shop/a, /shop/a/b, etc.
We need a simple page at /dashboard that shows a list of projects. How would you create the route segment in a Next.js 13 app directory to serve this page?
If you add a folder named profile under app but forget to include a page.tsx, what does Next.js render when a user navigates to /profile?
How would you define a dynamic route segment to capture a product ID under /products/[id] using the new app router?
Your team added a new dynamic segment [category]/[slug] but the page returns a 404 in production while it works locally. What could be causing this and how would you troubleshoot?
We want to share a layout between /blog and /blog/[slug] but also have a separate loading UI for the slug page. How would you structure the route segments and config files to achieve this?
Explain the trade‑offs between using a folder named (admin) as a route group versus a regular folder for admin routes in a large codebase.
Our monorepo has dozens of feature teams each adding their own route segments. How would you enforce a consistent naming convention and segment configuration to avoid route collisions and keep bundle size low?
When using segment config to set revalidate and dynamic options, what are the performance implications at scale, and how would you decide which segments get static vs dynamic rendering?
Describe how you would migrate an existing pages‑based /shop/[id] route to the new app router, handling data fetching, loading UI, and error handling without breaking existing SEO.
A legacy product line still uses the pages router while the rest of the app has moved to the app router. How would you design a phased migration strategy that leverages route segments, minimizes duplication, and keeps cross‑team deployment pipelines stable?
In a multi‑region deployment, route segments can affect caching and edge rendering. How would you architect segment configurations to ensure consistent latency and cache invalidation across regions?
If you need to expose a set of internal APIs under /api while also serving public pages, how would you structure route segments and middleware to enforce security boundaries and avoid accidental exposure?