Open tylerfilla opened 8 years ago
well?? does this mean that if you set a condition like sell @ 22 it won't go through because of the parsing issue?
this seems like a pretty important thing to fix!
any updates??
Actually, this issue is on the receiving end. This won't hinder a request being sent, but is something to consider when reading a response (that is, you can't really know if you're going to get a string or a number wherever they send an amount back). This lib doesn't attempt to interpret the responses.
Poloniex sporadically returns monetary values as a healthy mix of numbers and strings, and even uses numbers where strings are documented and vice-versa. This is all fine and dandy when the data is in JSON form, but when deserialized by
JSON.parse()
, I believe this may be cause for concern if the value is particularly large. Those astronomical orders on DIEM come to mind here.Option 1
I am aware of a particular JSON parsing solution called
json-bigint
which offers aJSONbig.parse()
function and converts all numbers tobignumber.js
numbers, but this isn't particularly desirable. At the very least, we must add another dependency, but the code change would simply be a 3 character addition.Option 2
One could also regex the raw JSON string for any monetary values and surround them in quotes. I think this would be a more direct solution to the problem, but must match a set of specific cases. Maybe we could "generalize" the matcher to get all decimal point-containing numbers. The result would be easily integrated into the already-string-number-handling codebase.
Right now, I'm leaning toward option 2.
Edit: Even if I'm concerned about nothing, I still want there to be some consistency. This change would probably have to be opt-in so the user knows what to expect.