Hacker News Reader

Comment by PontifexMinimus | Hacker News Reader

From https://fresh.deno.dev/docs/getting-started/create-a-route :

> Routes are defined as files in the routes directory. [...] If the file name is contact.js and is placed inside of the routes/about/ folder, the route will handle requests to /about/contact.

I can't say I'm particularly keen on being told what directory to put files in, or or being told that I must only code exactly one endpoint in each file. Why aren't I allowed to code multiple endpoints (e.g. for related functionality) in the same file?

Also, in what directory do I put my files if the url is of the form /user/{username}/page/{pagename} ?

View on HN

You put square brackets around parameters. e.g., routes/greet/[name].tsx

https://fresh.deno.dev/docs/getting-started/dynamic-routes

To add on this: Looks like you can do that for directories as well. Here's how it works: https://github.com/lucacasonato/fresh/blob/4bb07f4bcebfc2056...

So the example above could be:

  user/[username]/page/[pagename].ts

Hmmm. I suspect there is some software out there that doesn't like directory names with square brackets in them.

This is the same thing I dislike about NextJS. What is the argument for using the filesystem as part of a framework's API?

In the case of Nuxt (which by default uses basically the same paradigm) I could circumvent this by using the package @nuxtjs/router.

I have no idea why this is the default behaviour, it sure feels something like a lot of people put a lot of work into and by then they didn't realise their fancy new feature doesn't make things better.

I think it’s a part of their convention over configuration philosophy. Say what you will about it, there are obviously drawbacks.

But I’ve noticed that it makes it easier to quickly understand new codebases in my organization. Everyone are using Next.js and all the apps have about the same file layout.

And it makes the routes easily greppable in VSCode/Ag/Telescope/CrtlP which I think is the thing motivating it.

I think it’s neat that having extremely fast project dir fuzzy finders has influenced framework design. Like how Django’s design is heavily influenced by how importlib works and would be completely different if Python modules worked differently.

I asked about this recently and got some interesting answers: https://twitter.com/SachaGreif/status/1534079292774445056

What is a good argument against it? It makes understanding the layout of the website easily and saves you from having to come up with your own <custom> conventions around it.

I generally prefer keeping all the configuration in as few languages as possible and preferably in a single language. Adding filesystem-based config where a config option object in the main language of javascript would suffice goes against that.

Also, given a filesystem config, now I'm forced to have many very small files around for each route where each file is most likely just a call to another service handler. I'd prefer to mash most into bigger files that handle related but distinct routes.

Less important, but comes up, it's nice to be able to match routes based on code and not just string equality ... e.g. everyone seems to like having routes for usernames start with '@'

Reply on news.ycombinator.com