Description
@yashshah1 pointed out a problem with _.toQuery
and _.fromQuery
: through stringification, falsy values are being "upgraded" to truthy if you encode them and then decode them again. For example, _.fromQuery(_.toQuery({a: null}))
returns {a: 'null'}
.
@yashshah1 proposed the following solution in #229 (comment):
What I am suggesting is a change in both
toQuery
andfromQuery
.Proposed behaviour:
_.toQuery('{ a: '', b: null, c: undefined, d: '10' }') // a=&b=&d=10 _.fromQuery('a=&b=&d=10') // { a: '', b: '', d: '10' }Reasoning
The idea is that toQuery and fromQuery need to be as complementary to each other as possible, one drawback that's seen already is that numbers need to be re-parsed. Wrt falsy values, however, I think there has to be a special provision as described above.What we gain by this is that null values are re-encoded as empty strings, which is falsy, and undefined isn't included in the object, which leads to almost the same usage in a few cases.
var obj = { a: '', b: null, c: undefined, d: '10' } console.log(obj['c']) // undefined obj = _.fromQuery(_.toQuery(obj)) console.log(obj['c']) // undefinedThis might lead to a change in the behaviour of
fromQuery
and I am happy to raise a PR should this be acceptable.
I'm not sure whether this approach would be the right solution, for a couple of reasons:
- Information loss:
undefined
,null
and the empty string''
could no longer be distinguished. - What to do with numeric zero?
- How does this align with jQuery's encoding conventions?
However, this is something we can discuss. Let's do that here.