Number parsing

[ljharb]

Number parsing

[hueniverse]

This would be completely unpredictable.

[ngryman]

Why that?

jQuery does it pretty well: https://github.com/jquery/jquery/blob/c869a1ef8a031342e817a2c063179a787ff57239/src/core.js#L214.

function isNumeric(obj) {
  return !Array.isArray(obj) && (obj - parseFloat(obj) + 1) >= 0;
}

[hueniverse]

No. It will break my code because I always expect strings, not numbers.

[ngryman]

Which code, the parsing code?

If so leave it intact, and walk over the final object when you are about to return it, like here I guess: https://github.com/hapijs/qs/blob/master/lib/parse.js#L146.

Sorry, but I don't understand why this would be so complicated, perhaps I'm missing something... If so I'd really like to have more details :)

[gergoerdosi]

It can break code which for example relies on concatenation. '2' + '2' returns 22, but 2 + 2 returns 4. It is easier and safer to write code if the type of the returned value is always a string.

[ngryman]

@gergoerdosi So if we are talking about user code, I totally can understand that.
We are talking about backward compatibility.
number parsing would be a new feature hidden behind a new option which is disabled by default.
This would not break any existing code.

[hueniverse]

There is no point. If you want this as an option, write your own module on top of qs that checks for numbers and parses them. There is nothing wrong with layering your modules. If everyone starts using your module because it is a feature they really want, we can move it into qs.

[ngryman]

Ok, seems legit.
Thanks.

[ngryman]

FYI, I published qs-numbers: https://github.com/ngryman/qs-numbers.
It passes your tests with adjustments for number values.

[jerone]

I'm wondering why the (official) JSON standard isn't followed from the beginning?

Now I have to server-side convert all string matching the number-pattern to real numbers. Maybe add an option strict to comply to the standards and keep backwards compatibility.

http://json.org/
https://www.ietf.org/rfc/rfc4627.txt
http://rfc7159.net/rfc7159#rfc.section.6
http://www.ecma-international.org/ecma-262/5.1/#sec-8.5
https://github.com/douglascrockford/JSON-js/blob/master/json.js#L294

---

@ngryman commented on 28 sep. 2014 17:32 CEST:

FYI, I published qs-numbers: https://github.com/ngryman/qs-numbers.

It passes your tests with adjustments for number values.

👍

[ljharb]

@jerone because http query strings have nothing to do with json, so that'd be the wrong standard to follow?

[faceyspacey]

it would force query URLs to look like this: `?foo='1'&bar=1' -- may or may not be a bad thing. If it was the path, you certainly wouldn't want: /foo/'1'/bar/1.

[mehmetaydogdu]

Given the fact that parse and stringified are opposite of each others, I expect to find a way to get the same value once I stringified and then parsed a given number. But that is not the case as below. The default behaviour can be kept for compatibility but there can be an option to get number values explicitly.

const expected = {a:1}
const str = qs.stringify(expected)
const actual = qs.parse(str)
// => { a: '1' }

[ljharb]

That's not a reasonable expectation; you can't round trip through JSON.parse and JSON.stringify either.

[dragon-master-5892]

my custom number mapping here:

// add your numbers to 'Num(YOUR NUMBER)' like this: { price : 'Num(125.35)' }

const _ = require("lodash");
function deepMap(obj, iterator, context) {
return _.transform(obj, function (result, val, key) {
result[key] = .isObject(val) /*&& !.isDate(val)*/ ?
deepMap(val, iterator, context) :
iterator.call(context, val, key, obj);
});
}

_.mixin({
deepMap: deepMap
});

let myObject = {
'manufactured_year.id': {
'$gte': 'Num(1900.25)', '$lt': 'Num(125+(1933/2))', "depp2": {
'$gte': '+2400', '$lt': 'Num(-45)'
}
}
}

let query = qs.stringify(myObject );

let q = qs.parse(query);

deepMap(q, function (v, k, o) {
if (v) {
if (new RegExp("(Num)+([0-9]*)").test(v)) {
eval("o[k] = " + v.replace("Num", "Number") +";" );
}
}
});
console.log(q);