URL-decoding query strings in onUrlChanged before passing them to user code seems very nice, but there's one scenario you may not have considered: ampersands in query values. E.g., according to the documentation, the URL https://candystore.example.com/placeOrder?candyName=M%26M&quantity=5 would parse to ["placeOrder", "?candyName=M&M&quantity=5"], which would then confuse the Javascript URLSearchParams constructor when the end user tries to use the Route.Query active pattern. (I tested it on Google Chrome, and the result was that candyName had the value "M", and there was another key called M with the value "").
Since URLSearchParams already handles percent-decoding, I think it's better to not decode the query string in onUrlChanged, but just pass it unchanged to the user code, which can then safely use Route.Query to ensure a valid match against something like ["candyName", name] which will then place the string "M&M" into name.
URL-decoding query strings in
onUrlChanged
before passing them to user code seems very nice, but there's one scenario you may not have considered: ampersands in query values. E.g., according to the documentation, the URLhttps://candystore.example.com/placeOrder?candyName=M%26M&quantity=5
would parse to["placeOrder", "?candyName=M&M&quantity=5"]
, which would then confuse the JavascriptURLSearchParams
constructor when the end user tries to use theRoute.Query
active pattern. (I tested it on Google Chrome, and the result was thatcandyName
had the value"M"
, and there was another key calledM
with the value""
).Since URLSearchParams already handles percent-decoding, I think it's better to not decode the query string in
onUrlChanged
, but just pass it unchanged to the user code, which can then safely useRoute.Query
to ensure a valid match against something like["candyName", name]
which will then place the string"M&M"
intoname
.