[File-Router] wildcard view is not matched if subdirectories with parameters in their name exist

[taefi]

Describe the bug

There is a case for handling the wildcard route params that seems to be edgy and doesn't provide a good DX.

With a directory structure like this:

/views
├── customers
│   ├── {id}
│   │   ├── edit.tsx
│   │   └── @index.tsx
│   ├── @index.tsx 
│   └── new.tsx
└── {...wildcard}.tsx

Due to the existence of the {id} directory under customers, navigating to the /customers/new/123 is not matched to the wildcard view at the root (under views), and will not match anything else either.

The workaround is to add another {…wildcard}.tsx under views/customers/{id} (and not under the view/customers/ because this is not get matched either).

Expected-behavior

With the described behaviour, for implementing a simple "Not Found" view, the users need to pollute the views subdirectories by adding many wildcard views (under each directory that has parameter directory such as {id}, which happens to be a common case).

I'd expect that the wildcard view defined under the root directory to handle all the non-matched routes.

Reproduction

Any project from the start with the above-mentioned view directory structure reproduces the issue.

System Info

Tested with 24.7.0.beta1

[platosha]

Note: a top-level src/main/frontend/views/{...wildcard}.tsx will override Flow fallback. However, let's consider adding a 404 handler that takes server-side routes into account as a separate feature.

[platosha]

We could reuse the logic we have for adding Flow fallback for the wildcards.

[platosha]

During discussion, we realised that we need a better definition for the expected FS router behavior regarding various combinations of:

• wildcard routes
• layouts
• server-side fallback
• custom 404 handling

[platosha]

Let's also consider behavior with #3344

[taefi]

The following are valid cases that are not easy to achieve due to how the React Router is configured based on the directory structure:

1. It should be easy to register one global custom "404 - Page Not Found" route/view in an application that matches whatever is not matched directly with the defined routes in Hilla and Flow. If this functionality is supposed to be implemented using the wildcard view/route, I expect the views/{...wildcard}.tsx to match all the undefined routes in Hilla and Flow.
   For example, with a directory structure like this, I want the views/{...wildcard}.tsx to match /123, /customers/edit/abc123, /customers/123/aaa, and etc.:

/views
├── customers
│   ├── {id}
│   │   ├── edit.tsx
│   │   └── @index.tsx
│   ├── @index.tsx 
│   └── new.tsx
└── {...wildcard}.tsx

2. Having a directory structure as the following example (a wildcard view right next to a {param} directory) should result in error so that the user is not confused why the wildcard route/view is not matched:

/views
└── products
    ├── {id}
    │   ├── edit.tsx
    │   └── @index.tsx
    ├── @index.tsx 
    ├── new.tsx
    └── {...wildcard}.tsx

3. When there's a views/{...wildcard}.tsx present, I expect not having an @index.tsx at the root of the views/ results in / to be matched with the {...wildcard}.tsx. There's also separate issue for this: [FS-Router] wildcard route is not match when there is no @Index.tsx under views dir #3315

[platosha]

In case if global wildcard should not apply to /customers/..., it could be moved to another directory like so:

/views
├── customers
│   ├── {id}
│   │   ├── edit.tsx
│   │   └── @index.tsx
│   ├── @index.tsx 
│   └── new.tsx
└── {{fallback}}
    └── {...wildcard}.tsx

[platosha]

Considering the use cases above, it would make sense to make {...wildcard}.tsx also matching deep. Note that this would be a behaviour altering change.