[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 have 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