5 ms·

Yeah, so I do a lot with JSON right now, and having some kind of spec for APIs is pretty important. My biggest pain point is dates, since there's no simple way

by pfooti 10y ago

Yeah, so I do a lot with JSON right now, and having some kind of spec for APIs is pretty important. My biggest pain point is dates, since there's no simple way to throw some JSON at JSON.parse and get a date out. You have to know, a priori, what fields are dates and do some follow-up. There's other issues with some fields sometimes getting serialized as string representations of themselves (e.g.: "10" vs 10, or "false" vs false). On the other hand, I did a lot with XML in the 00s, and I sure don't want to go back to dealing with that anymore. I'm sure the world has come a long way since SAX was the thing to use for XML, but that experience left me so deeply scarred that I'm willing to just write an ad hoc schema on my frontend and say, "after JSON.parse, go in and coerce these fields to be int / bool / Date, etc". Not great for interop, but what the hey.

PretzelFisch 10y ago
Why we could not have # as a date prefix and suffix boggles my mind. And comments, if we want to use JSON for a config file we need to agree to allow // and /\ to temporarily comment out properties and object.
- sopooneo 10y ago
  Is your idea of having # as a date prefix and suffix compatible with having json be a subset of valid javascript? Because that was one of its original selling points. Are you thinking something like { "business": "Jim's Hat Shop", "date_visited": #2016-05-03# } Or were you thinking { "business": "Jim's Hat Shop", "date_visited": "#2016-05-03#" }
  - PretzelFisch 10y ago
    I was thinking { "business": "Jim's Hat Shop", "date_visited": #2016-05-03# } because the parsing would be simple while the other would work.
    - pfooti 10y ago
      Personally, this isn't bad - some kind of literal notation for date objects seems like a good idea (we already have octal and binary literals). The other option ("#date#") is bad, IMO, since it's a magic string. I don't like magic strings because they blow up at unexpected times. Imagine the notice to the users: "please stop using the hashtag #racecar#, we know palindromes are cool, but it is causing our database to crash". I had similar issues with CDATA blocks in XML, actually - escaping strings to afford reasonable parsing is never fun.
      - sopooneo 10y ago
        Your note about octal and binary literals sort of goes back and forth compared to the idea of date literals for me. Because octal and binary literals are supported in vanilla javascript, but are not explicitly supported in JSON. However, throwing them in seems like only a minor transgression since they are native to javascript, and are effectively just another representation of a number. On the other hand, the date literal you suggest is not part of javascript. And on that note, why not just use timestamps for dates in json?
    - sopooneo 10y ago
      But isn't it a huge change to make json not be valid javascript? These days no one in good conscience just uses "eval()" in a js app, so maybe it doesn't matter anymore, but still, it seems like that is suggesting a massive departure.
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 ago
  I 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.

by pfooti 10y ago

PretzelFisch 10y ago

Why we could not have # as a date prefix and suffix boggles my mind. And comments, if we want to use JSON for a config file we need to agree to allow // and /\ to temporarily comment out properties and object.

sopooneo 10y ago
Is your idea of having # as a date prefix and suffix compatible with having json be a subset of valid javascript? Because that was one of its original selling points. Are you thinking something like { "business": "Jim's Hat Shop", "date_visited": #2016-05-03# } Or were you thinking { "business": "Jim's Hat Shop", "date_visited": "#2016-05-03#" }
- PretzelFisch 10y ago
  I was thinking { "business": "Jim's Hat Shop", "date_visited": #2016-05-03# } because the parsing would be simple while the other would work.
  - pfooti 10y ago
    Personally, this isn't bad - some kind of literal notation for date objects seems like a good idea (we already have octal and binary literals). The other option ("#date#") is bad, IMO, since it's a magic string. I don't like magic strings because they blow up at unexpected times. Imagine the notice to the users: "please stop using the hashtag #racecar#, we know palindromes are cool, but it is causing our database to crash". I had similar issues with CDATA blocks in XML, actually - escaping strings to afford reasonable parsing is never fun.
    - sopooneo 10y ago
      Your note about octal and binary literals sort of goes back and forth compared to the idea of date literals for me. Because octal and binary literals are supported in vanilla javascript, but are not explicitly supported in JSON. However, throwing them in seems like only a minor transgression since they are native to javascript, and are effectively just another representation of a number. On the other hand, the date literal you suggest is not part of javascript. And on that note, why not just use timestamps for dates in json?
  - sopooneo 10y ago
    But isn't it a huge change to make json not be valid javascript? These days no one in good conscience just uses "eval()" in a js app, so maybe it doesn't matter anymore, but still, it seems like that is suggesting a massive departure.

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 ago
I 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.