Code based routing

[SoulEvans07]

Description

One of the main reasons I'm trying to move away from NextJS is the last 1.5 year struggle with file based routing which cannot adequately support highly dynamic routing solutions other than chucking a catchAll at the root and doing the routing by hand.

At that point the under documented magic done by a framework to support file based routing only gets in the way while a code based approach is much more predictable and understandable because you can actually read the code instead of the need to read the whole framework code to figure out what else can impact routing.

I know my use-case might not be the biggest priority for a framework maker, but having a first party option to change the framework into code based routing would make it a lot more useful and versatile while adhering to the first value stated on the framework's site: Control.

[brillout]

the last 1.5 year struggle with file based routing which cannot adequately support highly dynamic routing solutions other than chucking a catchAll at the root and doing the routing by hand.

Can you elaborate on that?

[brillout]

And, to be clear, we're very much open for this (we have ideas).

Personally, I do see the power of defining things in a programmatic fashion (e.g. Route Functions).

The more we know about use cases the better.

[SoulEvans07]

One of our current clients has a need for multiple micro-sites all of which are serving multiple countries speaking different languages. Such micro-site have (mostly) the same content and functionality across countries but translated to the regional language and under different domains.
Most i18n libraries want to handle translations by path (/en-GB/[...path]) or have weird limitations for domain mapping but so far so good.

But another requirement is to have the same pages under translated urls for the regions for better SEO scores.
(unfortunately there are pages which have different depths for the same page, eg.: /vouchers/:id might look like /gifts/vouchers/:id - translated to different languages of course).

And in one of the micro-sites - I'm currently working on - they requested an extra layer of complexity.
There is 2 pages in this site:

• a details page - /product/:id (of course 'product' is translated to 3 regions)
• a listing page with a store and category filter - /[store-slug]/[category-slug]/
  • category-slug is optional and comes from backend (translated)
  • store-slug part is always there
    • if there is no store selected there is a placeholder which again is a translated string
    • otherwise the store slug is also coming from backend

And the original request was even more absurd, but I wasn't able to convince them to simplify it even more by moving the store and category into query params.

These patterns are only solvable in file based routers by using an optional catchAll dynamic route [[...path]].tsx and then validating the router.query contents and branching out based on that on both the server-side and client-side.
(The examples are in Next because that's what we are using right now, but because of my struggles I'm looking for other alternatives for my personal projects and just to have them in my back pocket for the future)

I did miss this Route Functions part of the Vike documentation and at first look it looks promising but I still haven't wrapped my head around how this interacts with other parts of the framework so I cannot comment on it yet.