Drawbacks of using single [[...slug]].js vs Next.js file-based routing?
[[…slug]].jsfile that handles all your routes than manually duplicating logic from file to file? The more I work with Next the less I’m sure the file based routing is worth it.
This question is about general Next.js routing architecture rather than Sanity-specific functionality. You'd get better answers in Next.js-focused communities like the Next.js GitHub Discussions, the Next.js Discord, or Stack Overflow with the next.js tag.
That said, if you're building a Sanity-powered site with Next.js and finding yourself duplicating logic across route files, there are some Sanity-specific patterns that might help reduce that duplication:
- Shared data fetching utilities: Create reusable functions for your GROQ queries and Sanity client calls that can be imported into any route file
- Component-based templates: Keep your route files thin by moving shared logic into components that handle their own data fetching with Sanity's Visual Editing patterns
- Content-driven routing with Sanity: Use Sanity's document types to drive your routing strategy rather than fighting against Next.js file-based routing
The routing architecture decision itself (catch-all vs. discrete files) is a Next.js concern that applies regardless of your CMS, so the Next.js community will have more targeted advice for your specific use case!
Show original thread19 replies
Was this answer helpful?
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.
