Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix encoding/decoding inconsistency when using values that need scaping #33

Merged
merged 2 commits into from
Apr 4, 2016

Conversation

irae
Copy link
Contributor

@irae irae commented Apr 2, 2016

Since makePath uses pathToRegexp which in place uses encodeURIComponent for all values, when getRoute tries to match a URL generated by the router itself, it returns a double enconded value.

I suspect this is the root cause for fluxible-router to avoid using parsed URLs and bookeeping the origURL instead.

I added tests to both match (indirectly through getRoute) and to makePath. Notice that if you comment or remove decodeURIComponent from the implementation, only 1 of the tests fails. This proves the undesired inconsistency.

I do hate JSON in URLs and I know it is a bad practice, and I do want to remove this from the application I am working on (nope, I didn't introduce in the first place). But I believe this to be beneficial to the router... who does not want to support /emoji/😍/used/in/paths?

@mridgway

Since `makePath` uses pathToRegexp which in place uses encodeURIComponent for all
values, when getRoute tries to match a URL generated by the router itself, it returns
a double enconded value.

I suspect this is the root cause for fluxible-router to avoid using parsed URLs
and [bookeeping the origURL instead](1)

I added tests to both `match` (indirectly through `getRoute`) and to `makePath`. Notice
that if you comment or remove `decodeURIComponent` from the implementation, only 1 of the
tests fails. This proves the undesired inconsistency.

[1]: https://github.com/yahoo/fluxible/blob/2be37f6df6ef5d5ed7c31fae5ec14843f924b213/packages/fluxible-router/lib/History.js#L66-L73
@mridgway mridgway added the ready label Apr 2, 2016
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 351dfe9 on irae:fix-matcher-with-json-values into 134132e on yahoo:master.

@mridgway
Copy link
Collaborator

mridgway commented Apr 4, 2016

LGTM. Potentially a breaking change but could also be considered a bug as well. Open to thoughts on this.

@lingyan
Copy link
Member

lingyan commented Apr 4, 2016

This is more like a bug fix. but given the possibility of breaking change, we can publish this under 2.0.

👍 @irae Thanks for fixing.

@irae
Copy link
Contributor Author

irae commented Apr 4, 2016

I updated the PR with changelog and version bump to 2.0.0

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 152e4b9 on irae:fix-matcher-with-json-values into 134132e on yahoo:master.

@lingyan
Copy link
Member

lingyan commented Apr 4, 2016

👍

@mridgway
Copy link
Collaborator

mridgway commented Apr 4, 2016

👍 Thanks for the notes as well.

@mridgway mridgway merged commit c4e2e84 into yahoo:master Apr 4, 2016
@mridgway mridgway removed the ready label Apr 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants