Fix: do not encode slashes in catch-all routes #2291
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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