Hacker News Reader

Comment by hermanradtke | Hacker News Reader

I am not a fan of the “directory structure creating an implicit router” convention of next.js. I wish I would define a handler in code instead.

View on HN

I never liked it either. At my last job I actually had a system which generated the Next.is pages folder based on a route config. The irony being that at build time, Next would then turn this folder into an internal route config that probably looked quite a lot like mine.

Oh interesting. Why not? Directory and file based routing is my favorite feature of Next.js, Remix, and other frameworks that do it.

It makes route localization a second-class citizen in the framework at best, or a totally unsupported hack-your-own-solution thing at worst.

if it helps, you could use middleware in next.js to handle routing to separate folders easier.

Middleware won't work if you use "next export" to get a truly static site though, which is by far my preferred mode of operation whenever possible.

This is what I meant when I said "second-class citizen at best".

ah I see. Maybe try the route rewriting in next.conf.js? I think thats what the file is. That might work for static sites.

It seems like a path prefix like "/en/books" or "/es/books" could be supported with a base url config.

Localized path segments like "/books" or "/libros" could be supported with a path segment mapping configuration.

It should work fine in theory. I guess those configs don't exist yet. Or is there something else that route localization requires?

I don't like this approach either as maintenance gets complex over time. Changing routes in my React-router project is one file, one commit that's easy to verify, try changing a dozen routes with Next and you end up with a dozen of files moved around, with folder structure possibly impacted as well, I see this as an anti-pattern.

That's true, the pull request diff viewer does not make viewing file renaming very clear and there could be conflicts.

On the other hand, what I see in practice is adding or removing context providers and layout components in the react router file, it becomes huge, and all the diffs change all of the lines with new indentation.

It gets so ugly as soon as you have dynamic routes like `[...postName].ts`

I've worked with both. There are days when I prefer a programmatic approach, and days I love the file-based router. With the introduction of routing middleware [0], Next.js finally offers anything I'd want to build.

An option would be to add a catch-all route [1] at the root and implement your own code-based routing. You can still define the desired paths using getStaticPaths [2] but my guess is that some functionality like route-based code splitting will stop working.

0 - https://nextjs.org/docs/advanced-features/middleware

1 - https://nextjs.org/docs/routing/dynamic-routes#catch-all-rou...

2 - https://nextjs.org/docs/basic-features/data-fetching/get-sta...

I prefer the directory structure approach as it makes it a lot easier to find the code related to a route. In other approach you can spend a lot of time finding the right files. The directory structure based routing really makes things a lot more convenient. I can imagine it's annoying when you move routes/urls a lot

Coming from a React Router background, the Nextjs file structure is a bless to work with

Reply on news.ycombinator.com