search

PolymerElements / iron-location

A Polymer element that manages binding to the page's URL.
22 stars 41 forks source link

iron-location shouldn't decode window.location.search #51

Closed rictic closed 7 years ago

rictic commented 8 years ago

Decoding the entire query component at once (at least with decodeURIComponent, perhaps we should use decodeURI instead?) is an error because it is impossible to distinguish the urls:

/?foo=bar&baz -- two query parameters /?foo=bar%26baz -- one query parameter

LostInBrittany commented 8 years ago

Same thing with %2F and /, I cannot differentiate url paths /foo%2Fbar/foobar and /foo/bar/foobar.

It's a big problem for me when using app-location as router on my app. Before using app-location I used excess-router and that kind of schema worked as a charm.

I am sure there is a good reason to use decodeURIComponent in iron-location, but I fail to see it...

rictic commented 8 years ago

Encoding and decoding pieces of the URL is subtle. If possible, I'd like iron-location to take on that work rather than every user needing to understand and perform encoding and decoding at every usage point.

e.g. it would be nice if this just worked:

  <paper-input value="{{searchQuery}}"></paper-input>
  <iron-location hash="{{searchQuery}}"></iron-location>

If iron-location doesn't handle encoding and decoding, then you'd need to use two separate fields and write two change observer functions to handle encoding and decoding, and if you make a mistake then your two observer functions can become mutually recursive, crashing the page. And if the user doesn't do encoding and iron-location doesn't do encoding then at a minimum links will break, as the mapping between the application state and the URL will be broken for any urls with characters that are automatically encoded by window.history.pushState.

So, in short, this is important, and it's a decent amount of pain to ask users to take on.

With the query params case the semantic meaning of /?foo=bar&baz is very different than /?foo=bar%26baz and there there is a simple solution, we just push the work of decoding that character downstream.

I'm less sure about /foo/bar/foobar and /foo%2Fbar/foobar because if you want to differentiate those two then what about users that want to differentiate /foo from /%66%6F%6F?

TimvdLippe commented 7 years ago

This issue can be closed as #56 has been merged. The Fixes #51 was referenced in a comment instead of the description.