Questions about the catch all syntax

[aldencolerain]

What problem does this feature solve?

The documentation regarding catch-all routes can be improved. Specifically the section describing why the catch all parameter should be repeatable. Also, the suggested example parameter name "pathMatch" is a little generic and confusing. The term does not build any immediate intuition for people coming into a new project that the route is a catch all.

What does the proposed API look like?

Improving "pathMatch" example parameter

I'm sure others have better ideas to improve "pathMatch" as the suggested catch all parameter name. "Match" is implied because it wouldn't be captured if it wasn't a match, so I suggest "Match" be removed. To make it more clear we could use "completePath", "catchAllPath", "anyPath" or even just "path" for the example without repeating. For the example with repeating we could use "pathPart" or something.

Clarifying the motivation and recommendation to repeat

Regarding the recommendation of making the catch all parameter repeatable. If the regex matches "anything" not just any chars between "/", this is not clear. We could change "anything" to be "anything including slashes" to make that more obvious.

The justification is also confusing for two reasons.

First, why would making a param repeatable make a "." regex not match slashes? That seems counter intuitive because "." regex matches slashes. It also looks strange because the "*" and "?" are reused out of a regex context. but perhaps that is just an artifact of the api.

Second, why is this array preferable for programmatic navigation, can we can just navigating using fullPath instead of reconstituting the parameters? Also not sure when the need for programmatic navigation from a 404 or match all route come up.

Thank for you reviewing. I may have misunderstood the documentation, but I hope the issue it motivates one or two small changes to improve that section's clarity.

[aldencolerain]

Alternatively we could consider keeping the syntactic sugar * and instead of warning the user just make it into the proper regex route. I realize its only one route, so its not an issue of saving typing but it may be an issue of saving mind share. That * was intuitive and aligns with many other familiar systems. I guess though it wouldn't be obvious what parameters were generated.