Open jason0x43 opened 7 years ago
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
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.
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'