Is nested path params supported?

[coodoo]

Trying to simulate the URL structure like github.com I've got these routes:

const routes = {
	'/': () => <Home />,
	'/user': () => <User />,
	'/user/:repo': () => <Repo />,
	'/user/:repo/issues': () => <Issues />,
	'/user/:repo/issues/:issue_id': () => <Issue />,
}

I expect <Issue /> shall be invoked and shown on screen when I visit :

http://localhost:5173/user/repo_foobar/issues/222

and I could access issue_id (which should be 222) like this:

const [path, pairs] = usePathParams('/user/:repo/issues/:issue_id')

But for some reasons <Issue /> never showed on screen.

Did I miss something in the route config?

[coodoo]

After further tinkering around to find out the root cause is issue_id, changing it to issueId then everything worked like a charm. Now wondering why underscore or dash isn't supported as valid variable name in routes?

PS. Please feel free to close this issue since the problem is solved now.

[kyeotic]

Now wondering why underscore or dash isn't supported as valid variable name in routes?

Not much is, its just this regex: /:[a-zA-Z]+/. I'm opening to changing these if you have a good reason, but if not then I should at least document this somewhere. I will leave this open in the meantime/

[coodoo]

One good reason to support them both being following characters are all legal and supported in an URL?

; , / ? : @ & = + $ - _ . ! ~ * ' ( ) #

source

[n33pm]

These are only legal and supported URL characters but there is no need do support these characters in the route matcher.

In my humble opinion keep it simple. each additional character ( route matcher ) can lead to unexpected problems.

[kyeotic]

I'm with @n33pm, I don't see a good reason to match all valid characters, especially characters that cannot be valid JS variable characters, since that's ultimately what this route matcher produces (I know you could use quotes but that seems clunky to me).

For the pythonista's I can see why having underscore would be nice. Unfortunately changes to this part of the code constitute a breaking change for the library, so I plan on doing this exactly once. So, I will open a new issue for it where it can be discussed more visibly.

[coodoo]

Actually I agree with everyone here on keeping it simple is good, also not supporting _ is really not that of a big deal, just make sure to note that in the doc so future users know ahead of time! 🙌

[kyeotic]

I've changed my mind on this and plan to add support for more URL characters.