React-router: Contents of `match.params` differs based on containing Router

[gbenson-wikia]

Version

4.1.1

Steps to reproduce

RoutesMain.jsx:

...
const RoutesMain = () => (
    <Switch>
        <Route
            exact
            path="/foo/:broken/bar"
            render={
                ({ match }) => {
                    console.log(match.params.broken);
                    return (
                        <div>
                            {match.params.broken}
                        </div>
                    );
                }
            }
            />
    </Switch>
);
...

Test1.jsx:

...
<StaticRouter location="http://www.example.com/foo/broken%20case/bar" context={{}}>
    <RoutesMain />
</StaticRouter>
...

Test2.jsx:

import createHistory from 'history/createBrowserHistory';
...
<Router history={createHistory()}>
    <RoutesMain />
</Router>
...

Expected Behavior

When visiting http://www.example.com/foo/broken%20case/bar , the value of match.params.broken should be consistent regardless of where it's included. This is important in server-side rendering scenarios, where the node side will naturally want to use StaticRouter and the client side will naturally want to use BrowserRouter or equivalent.

Having the params URI decoded is preferable, so that match.params.broken will be broken case for this example.

Actual Behavior

When the context is StaticRouter, the value of match.params.broken is broken%20case. When the context is Router, the value is broken case.

[pshrmn]

The <StaticRouter> calls the parsePath function exported by history. The decoding, however, is performed in createLocation (which calls parsePath when given a string). We should probably just be importing createLocation in <StaticRouter>.

[gbenson-wikia]

I've added a pile of unit tests to help flesh out the param parsing coverage. Hopefully this helps get this specific issue resolved faster. ;)

Please let me know if there's anything fishy about the tests themselves, or if I can give additional context for any of this.

Thanks!

[NickCis]

I've found the same problem while using matchRoutes from react-router-config (1.0.0-beta.4)

[leidegre]

Any chance of getting this fixed? Having an URI encoding inconsistency within the router feels like an oversight rather than a feature? I'm reluctant to suggest a fix for this because I don't know how all pieces fit together but maybe a call to decodeURIComponent here is a good start?