Support more characters in path part matchers
See original GitHub issueThe current code for matching path segments to route props is quite simple: the regex: /:[a-zA-Z]+/. In at least one instance this surprised a user. As @coodoo points out This could be expanded to the following valid URL characters
; , / ? : @ & = + $ - _ . ! ~ * ' ( ) #
Since changing this is a breaking change for the library I am opening an issue to invite discussion on the topic.
The way I see it none of the following characters belong in a JS variable, so they should not be part of the route prop matcher.
; , / ? : @ & = + - . ! ~ * ' ( ) #
That leaves: $ _
. I think as part of a regex using $
could be confusing, and I also think its probably unlikely to be wanted. That leaves only _
. I am willing to create a breaking change to add this, but only once there is critical mass for it. Breaking changes are a cost to the userbase, and I don’t want to charge that cost if the benefit is to less than 5% of the users. Of course, I don’t have a good way to poll, or even a good idea of how big the user base is, but I do have a good handle on the number of people active on this repository and its about 10. So if I can get 3 people who want a breaking change in order to have underscores in route props I will make the change.
I will leave the issue open for 1 year, or until that happens, whichever comes first. Of course, the floor is still open for anyone that wants to defend one of the characters I didn’t like.
Issue Analytics
- State:
- Created 10 months ago
- Comments:5 (4 by maintainers)
currently the second route would match with
/users/n33pm_test
anduserId
=n33pm
. after the changeuserId_test
=n33pm_test
anduserId
isundefined
and both routes would match the same. probably it breaks ?!Sorry @coodoo I thought I responded to this, but I must not have hit enter.
It’s a breaking change because routes that match with an underscore will get a different variable passed in as a route parameter. That is the front-door API for the entire library, and changing the output like that would cause a previously functioning route to start failing. I know it seems like a minor addition to a regex, but that regex is the API for
useRoutes
.