Encoding of the parameters is now done by the matcher and is dependend on the matcher keys: every key has a keepSlash property that reflects if it should encode the slash character or not.
The keepSlash currently applies to all custom regex that either match a slash or contain one in their literal part, excluding lookaheads, lookbehinds and negative ranges. This is very simplistic but should be enough to cover both catch-all (e.g. "(.*)" routes) and explicit path regexes (e.g. "(deep/path/[a-z]*/)" )
I have also added a few tests to ensure everyting is working properly.
The Router > 'can redirect to a star route when encoding the param' test is currently failing as it sets a parameter with an urlencoded slash (%2F) and expects to find it as it is in the route. However, since this PR allows literal slashes in star routes, the actual url contains the sequence as a literal (%252F) rather than keeping the escaped slash.
I could edit the test, but I am unsure if this is behaivour that is being relied upon. In case it is, more work is needed to distinguish user-set urlencoded path segments from the normal usecase.
To test this PR I have updated the sandbox from #1638 here: codesandbox.io
This fixes #1638
Encoding of the parameters is now done by the matcher and is dependend on the matcher keys: every key has a keepSlash property that reflects if it should encode the slash character or not.
The keepSlash currently applies to all custom regex that either match a slash or contain one in their literal part, excluding lookaheads, lookbehinds and negative ranges. This is very simplistic but should be enough to cover both catch-all (e.g. "(.*)" routes) and explicit path regexes (e.g. "(deep/path/[a-z]*/)" )
I have also added a few tests to ensure everyting is working properly.
The Router > 'can redirect to a star route when encoding the param' test is currently failing as it sets a parameter with an urlencoded slash (%2F) and expects to find it as it is in the route. However, since this PR allows literal slashes in star routes, the actual url contains the sequence as a literal (%252F) rather than keeping the escaped slash.
I could edit the test, but I am unsure if this is behaivour that is being relied upon. In case it is, more work is needed to distinguish user-set urlencoded path segments from the normal usecase.
To test this PR I have updated the sandbox from #1638 here: codesandbox.io