URI Encoding/Decoding

[devonray]

Does the router perform URI encoding/decoding or should application code handle that? I'm seeing inconsistent behavior.

When navigating (href click or push) to a URI with a space in it (e.g. /search/all-results/foo bar) the store contains the space (in the pathname and params) and the browser URL bar displays an encoded URL (/search/all-results/foo%20bar) presumably provided by the router. This is convenient, as I don't have to do any URI encoding/decoding as the store contains the decoded version and the browser URL bar has a valid encoded URL. The href on anchors does contain the space, of which I'm not particularly fond.

The catch is that when refreshing the page, the store subsequently contains the encoded URI in both the pathname and params. If, instead, I URI-encode the space character in the original URI, the URI gets doubly-encoded such that /search/all-results/foo%20bar becomes /search/all-results/foo%2520bar in the browser URL bar.

FWIW I would advocate for all URI encoding/decoding to be handled by the application, not the router. Short of that, it would be good to have predictably behavior and ensure characters like = are supported as params. Currently I'm unable to obtain a string containing = as a param in the URI.

e.g.
Doesn't work (params.id === undefined):
/user/VXNlcjo2MTk4MDc4OTg3MTY5NDc3MzE=/profile for route /user/:id/profile
Works (params.id === "VXNlcjo2MTk4MDc4OTg3MTY5NDc3MzE"):
/user/VXNlcjo2MTk4MDc4OTg3MTY5NDc3MzE/profile for route /user/:id/profile

[stefvhuynh]

looks like this isn't an issue anymore. the history lib decodes the url on initialization (https://github.com/ReactTraining/history/blob/dca21eaa9230ae187c72ef657f70aac97cb172aa/modules/LocationUtils.js#L35), so the store will always contain decoded strings.