3 ms·
> There's other issues with some fields sometimes getting serialized as string representations of themselves (e.g.: "10" vs 10, or "false" vs false). With JSON
by BinaryIdiot 10y ago
> There's other issues with some fields sometimes getting serialized as string representations of themselves (e.g.: "10" vs 10, or "false" vs false).
With JSON.parse()? That would be a big failure of handling standard JSON if it did that. Do you have an example where JSON.parse() doesn't correctly parse JSON in the manner you suggest? Or really in any manner? I haven't seen it fail yet and if there are known failures it would be good to know about them.
https://jsfiddle.net/jb1wunpc/ https://jsfiddle.net/jb1wunpc/
- pfooti 10y agoI have the failure occasionally when I'm just shoving a JSON object into a PUT request, and the on the server side (hapijs, postgres) taking part of that JSON object and shoving it into a jsonb column type. In certain circumstances, the value in the database row was "10" rather than 10, which caused issues in queries against it (like WHERE documents.extended->>agenda_id = 10). I don't know where the issue really originated which part of transport or serialization, and I honestly don't know how common it really is - I just slapped some type coercions on the object I was putting into the jsonb field (which was necessary anyway, to protect against malicious user input) and called it a day. So it's probably not JSON.parse at fault here. EDIT to add: just looked over my notes, and it seems like the problem was likely originating in how I was treating option elements underneath a select in an html form. Somehow the value was getting set to a "10" instead of 10 on the form's model object, and that was getting pushed over the wire (serialized and deserialized) as a string.