Hacker News Reader

Comment by martpie | Hacker News Reader

Next.js is an awesome framework, but dynamic routing is still a mess, and clean URL masking [0] is unnecessary complicated: you have to add a route handler to Express.js, and you have to use 2 different props to your <Link> components to make it work.

The Next team explains it because they don't want to solve this problem by shipping a definition of all the route of the app [1] because it does not scale. But while it is true, it makes dynamic routes extremely painful to use. Hopefully it will be fixed soon.

Another thing not mentioned in the blog post is they started to rewrite the core of Next.js in TypeScript too, which is a big move!

  [0] https://nextjs.org/learn/basics/clean-urls-with-route-masking
  [1] https://github.com/zeit/next.js/issues/4989#issuecomment-442024894

View on HN

We had the same problem, and weren't happy with next-routes as a solution. Ultimately we ended up making our own library to handle routing. It's pretty low-level (some stuff is left for implementation in user-land), but so far it's been solid:

https://github.com/Zegocover/next-route-resolver

There is a bug right now related to query strings being hidden from the visible URL (they're still there as far as Next is concerned), but we'll be fixing that pretty soon.

Hey there!

Not sure if you've seen this guide here, but there is a way to setup dynamic routing with clean URLs that doesn't require adding your own server handler if you use Now v2 for deployments:

https://zeit.co/guides/custom-next-js-server-to-routes/

Also, I recently wrote about how I locally develop Now v2 apps with an example of SSR dynamic routes:

https://medium.com/digital-surgeons-engineering/how-to-set-u...

Is this Now only as I'm sure most of us don't use Now?

Yeah Now only

Thanks but no thanks!

This. I started out with a similar framework called nuxt.js but found the routing to be too limiting. It's a nice way to get started quickly, but once things become more complex you hit too many hurdles. In the end it pays to do the project setup yourself, which also helps a ton in debugging issues along the way.

Can you share what you found limiting with nuxtjs routing? Genuinely curious.

As you probably know, Nuxt.js uses a folder to url mapping, so say /src/views/contact/index.vue maps to /contact In my case I wanted to be able to change the url depending on the language of the user. And not by prefixing it with a /en/contact vs /de/kontact. To make matters more complicated, I serve multiple domains from the same node/express instance and determine the correct site data to render based on the domainname. There were plugins and hacks to make this somewhat possible, but it felt like going against the philosophy of nuxt.js. I still think it's a fantastic framework if your needs align with this type of routing. I ended up using the Vue SSR HackerNews repo as a template.

You can use custom routing and its actually recommended for bigger projects you can check it here if you want https://vuejsdevelopers.com/2018/07/16/7-tips-large-nuxt-app...

Thanks for the link. Good to see this is much easier now.

We are using `next-routes` and they are working really well for us.

Second this. In production for nearly a near now.

next-routes is good, but it was unmaintained for a long time, with issues and PRs (27 at the time of writing!) piling up. A new maintainer was just added [1] who seems more active, so hopefully things will improve.

[1] https://github.com/fridays/next-routes/issues/244#issuecomme...

Almost all of them are just version bumps. We wasn't needed anything for a year of usage.

> they started to rewrite the core of Next.js

This is such an important piece of information. Imagine you opt for Next and have to rewrite your app soon. I know, APIs can be backwards compatible and Next's next version will be backwards compatible but there is always something which doesn't work, sending you down the rabbit hole...

The core stays the same, they are only adding static types. I am certain they will make sure nothing meaningful will change in the outputted JavaScript, except for potential bug fixes uncovered by the types!

Your apps should not be affected at all.

> they are only adding static types.

The parent says something different and if it were just about adding types then you need just to add a file to DefinitelyTyped which I guess happened already.

Yes it says they are "rewriting the core in TypeScript", but that does not necessarily mean changing the code in any meaningful way. It means adding static types to the core itself, not only the interface (which DefinitivelyTyped is for).

Max is definitely right here. We're not planning to deprecate or "completely rewrite" anything.

We're not even "rewriting everything in Typescript at once". We're slowly converting files over one by one. No public APIs are changed. Furthermore, we have an extensive test suite of end-to-end tests for both development and production behavior.

Reply on news.ycombinator.com