Support more characters in path part matchers

The 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.

[n33pm]

const routes = {
  "/users/:userId": ({ userId }) => <div>{userId}</div>,
  "/users/:userId_test": ({ userId }) => <div>{userId}</div>
};

currently the second route would match with /users/n33pm_test and userId = n33pm. after the change userId_test = n33pm_test and userId is undefined and both routes would match the same. probably it breaks ?!

[kyeotic]

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.