Skip to content
This repository has been archived by the owner on Jul 30, 2018. It is now read-only.

Improve UrlSearchParams handling of booleans #279

Open
jason0x43 opened this issue Feb 1, 2017 · 2 comments
Open

Improve UrlSearchParams handling of booleans #279

jason0x43 opened this issue Feb 1, 2017 · 2 comments

Comments

@jason0x43
Copy link
Member

Currently, UrlSearchParams#toString will include key names for parameters with falsey values.

Test: new UrlSearchParams(<Hash<any>>{ debug: false, foo: 'bar' }).toString()

Expected output: 'foo=bar'

Actual output: 'debug&foo=bar'

@dylans dylans added the bug label Mar 6, 2017
@dylans dylans added this to the 2017.03 milestone Mar 6, 2017
@dylans dylans modified the milestones: 2017.03, 2017.04 Apr 2, 2017
@dylans dylans modified the milestones: 2017.04, 2017.05 Apr 29, 2017
@eheasley eheasley modified the milestones: 2017.05, 2017.06, long-grass Jun 6, 2017
@kitsonk kitsonk added the beta3 label Jul 27, 2017
@kitsonk kitsonk modified the milestones: 2017.07, long-grass, 2017.08 Jul 27, 2017
@kitsonk kitsonk modified the milestones: 2017.08, 2017.09 Sep 4, 2017
@dylans dylans modified the milestones: 2017.09, 2017.10 Oct 10, 2017
@kitsonk kitsonk removed the beta3 label Oct 30, 2017
@kitsonk kitsonk removed this from the 2017.10 milestone Oct 30, 2017
@kitsonk kitsonk added the beta5 label Oct 30, 2017
@kitsonk kitsonk modified the milestone: beta.5 Oct 30, 2017
@agubler agubler removed the beta5 label Jan 4, 2018
@agubler agubler removed this from the beta.5 milestone Jan 4, 2018
@ktiedt
Copy link
Contributor

ktiedt commented Jun 2, 2018

Since I was looking at UrlSearchParams already... is this ticket description actually the intended results? I would expect debug=false&foo=bar I would similarly expect { debug: 0, foo: 'bar' } to return debug=0&foo=bar falsey values are perfectly valid values and translatable to query params...

The only time it makes sense to skip a key would be if its value was undefined or null I would think?

This is also very closely related to #385

@jason0x43
Copy link
Member Author

The issue is that query params values can only be strings, and there’s no unambiguous way to represent anything else. Converting boolean false to ”false” or “0” would be reasonable so long as the code that eventually uses it understands the convention, but just converting a false property to a bare property name is definitely not.

It might be better to follow the spec of the URLSearchParams class, whose set method technically only accepts string values. For UrlSearchParams, the contructor might only accept objects of type { [key: string]: string }. This would at least force users of the class to manage string conversions themselves, avoiding any unexpected behavior.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants