directory based conditional routing

[SKhajeh]

What is it about?

transfer the database-stored-state oriented conditionals from rendering level to the routing level

What's the motivation for this proposal?

Problems you are trying to solve:

Currently:

User navigates to this url:
example.com/users/12312

this url hits this pattern:
example.com/users/[uid]

the corresponding index.tsx file(API endpoints etc.) is executed, and the reasoning(the if-else statements) about whether the user should receive a viewers or account owners rendering of that page is performed inside the components function. This makes the index.tsx (etc) file crowded, because it has to handle both of the situations in the same file which I guess its opposing to the principle of separation of concerns.

Goals you are trying to achieve:

• Making the index.tsx file less crowded.
• Enabling the developer to have a visual perception of different rendered versions of a route, by looking on the directory structure.
• Maybe enabling more optimization on the module pre-fetching process. By omitting some chunks that are not going to be rendered because the user is not logged in or the product is not in-stock.

Any other context or information you want to share:

In addition, it's a cool idea, 😄.

Proposed Solution / Feature

What do you propose?

Instead:
User navigates to this url:
example.com/users/12312

this url hits one of these patterns:
example.com/users/[uid].logged-in
eaxmple.com/users/[uid]

Code examples

there is a file "/src/routes/users/[uid].logged-in/logged-in.ts" which looks like this:

import type { routeHandler } from '@builder.io/qwik-city';
// other imports related to the database interactions
 
export const onNavigate: routeHandler = (request,...etc) => {
//some logic to check whether or not there is a user or a product with the corresponding id,
// if not:
// redirect to the 404 page

//some logic to check whether or not the session cookies or tokens provided by the request belong to a logged-in user, or the product is in-stock or the shops stock has run out of it.
// if not return a NavigateFalse object, otherwise return a NavigateTrue object.
};

if a NavigateFalse object is returned by the logged-in.ts file, the routing system passes to the next matched pattern and continues until it either receives a NavigateTrue return object or it runs out of "/src/routes/users/[uid].*" matched patterns and then it renders the file "/src/routes/users/[uid]/index.tsx".
Otherwise, it goes to the corresponding index file located inside of the directory for the matched conditional route, i.e. "/src/routes/users/[uid].logged-in/index.tsx

Additionally:

• I don't have a specific suggestion on how to order the tracing process of the pattern matching, but how clever it is, only the first match in the order is responsible for checking whether or not there is defined a product or user with the same id in the database. If the user or product is present in the database but the first match won't return a NavigateTrue object type, it needs to return a NavigateFalse object type in order for the routing system to look at the next pattern in the order.
• Maybe it's a good idea to chain the conditions this way:
  "/src/routes/products/[pid].in-stock.sales-active"
  and the corresponding route folder structure might look this way:

src/
└── routes/
   └── products/
       └── [pid].in-stock/
           ├── in-stock.ts
           ├── index.tsx         # for sale-inactive
           └── .sales-active/
               ├── sales-active.ts
               └── index.tsx         # for active-sale

Thanks for reviewing this idea, 🙏.

[wmertens]

hmm I'm not convinced. To know how a request will match you have to read all the files. The total amount of code is more because of extra boilerplate.

Also, all these file patterns are not very discoverable, you have to know about them in order to use them.

And a nitpick, directories starting with a dot are hidden by default.

[SKhajeh]

Thank You. Wouldn't all the files being converted into a single boilerplate-shaken one during compilation solve the issue of reading all the files for request matching? I mean anyway for the specific use case targeted here, whether the reasoning part of the code is all inside a single index.tsx file or it is distributed among a group of files based on every conditional case, all of the reasoning part of the code needs to be executed. And this proposal to a more degree leans towards being a DX feature, so that the framework hides away some annoying stuff from the developer.

[SKhajeh]

To address the issue of dot-prefixed hidden directories:

src/
└── routes/
   └── products/
       └── [pid].in-stock/
           ├── in-stock.ts
           ├── index.tsx         # for sales-inactive
           └── in-stock.sales-active/
               ├── sales-active.ts
               └── index.tsx         # for sales-active

The routing process needs a special case which looks for subdirectories starting with the same name as the conditional segment of the immediate conditional parent directory, in order to catch a possible condition chain.

[wmertens]

I must say I'm still unsure about how I should read this. I would much prefer to have a simple isInStock(request) ? <InStock /> : <NotInStock /> structure in the index.

I dislike too much magic and non-self-explanatory structures though.

[SKhajeh]

I dislike too much magic too, thanks.👍