Hacker News new | ask | show | jobs
by darepublic 530 days ago
doing some recent contract work I discovered someone putting this into a PR (comments my own)

```

let susJsonString = '...' // we get this parseable json string from somwhere but of course it might not be parseable. so testing seems warranted...

try { // lets bust out a while loop!

while(typeof susJsonString === 'string') { susJsonString = JSON.parse(susJsonString) }

} catch { susJsonString = {} }

// also this was a typescript codebase but all the more reason to have a variable switch types! this dev undoubtedly puts typescript at the top of their resume

```

I suppose this works?! I haven't thought it through carefully, it's just deciding to put your shoes on backward, and open doors while standing on your head. But I decided to just keep out of it, not get involved in the politics. I guess this is what getting old is like seriously you just see younger people doing stuff that makes your jaw drop from the stupidity (or maybe its just me) but you can't say anything because reasons. Copilot, ai assisted coding only further muddies the waters imo.

1 comments

This is totally fine. If you're given shit data this seems like a reasonable way to try to parse it (I would personally bound the loop).

Typescript is not going to make it better.

The problem is whoever is producing the data.

I think the complaint here is they have a string, which even has the word string in the variable name, and they turn it into an object at the end. Hence references to Typescript.

I suppose what is wanted is something like

let parsedJSON = {}

try { parsedJSON = JSON.parse(susJsonString) } catch { //maybe register problem with parsing. }

That's quite different though. It looks to be dealing with the case that a serialised object gets serialiased multiple times before it reaches that point of code, so it needs to keep deserialising until it gets a real object. E.g:

    JSON.parse(JSON.parse("\"{foo: 1}\""))
I'd guess the problem is something upstream.
Hmm, yeah ok, didn't pick this out of the

let susJsonString = '...'

example

but evidently it is not just that it is serialized multiple times, otherwise it shouldn't need the try catch (of course one problem with online discussion of code examples is you must always assume, contra obvious errors, that the code actually needs what it has)

Something upstream, sure, but often not something "fixable" either, given third parties and organizational headaches some places are prone to.

Yeah. I imagine that's a bandaid around having to consume a dodgy api that they didn't have access/permission to fix.

The blanket catch is odd though, as I'd have thought that it would still be outputting valid json (even if it has been serialized multiple times), and if you're getting invalid json you probably want to know about that.

probably some times the api comes out with an empty string.
The code is either going to loop once and exit or loop forever no
Putting this in my web console:

  let susJsonString=JSON.stringify(JSON.stringify(JSON.stringify({foo:1})))
  console.log("initial:", susJsonString);
  try { 
    while(typeof susJsonString==='string') {
        susJsonString = JSON.parse(susJsonString);
        console.log("iteration:", typeof susJsonString, susJsonString);
    }
  } catch {
    susJsonString = {};
  }
I see:

  initial: "\"{\\\"foo\\\":1}\""
  iteration: string "{\"foo\":1}"
  iteration: string {"foo":1}
  iteration: object {foo: 1}
A comment explaining the sort of "sus" input it was designed to cope with may have been helpful.
It will stop when it gets something that's not a string due to

    while(typeof susJsonString==='string') {
        susJsonString = JSON.parse(susJsonString);
as it'll keep reassigning and parsing until gets a non string back (or alternatively error out if the string is not valid json)
Now two of you are misunderstanding.

It’s applying the operation recursively.

Why the while loop
Because some upstream idiot is calling JSON.stringify several times.
I've seen this happen when someone's not familiar with their api framework and instead of returning an object for the framework to serialize, they serialize it on their own and return a string. Which then gets serialized again by the framework.
You came in so confident it was wrong, but it turns out you don’t really know what it does.

Please take a lesson from this. Good code is not the one that follows all the rules you read online. Your coworker you dismissed understood the problem.

I didn't know that JSON.stringify could be called multiple times on the same object and then unpacked via repeated calls to JSON.parse. So I was wrong on that. I think definitely this warrants a comment in the code, at the least explaining why this was taking place. The likely reason for the nesting was I think calling an LLM for a valid json object and somewhere in that workflow the json object was getting stringified more than once. I suspect this is the fault of the codebase and not the LLM itself, but it was typical of these devs to not ever investigate the api to understand what it was returning and rather just apply bandaid after bandaid.

I reserve my general opinion on the quality of this coder's work, as evidenced by the quality of the app itself among other things. But I guess you'd have to just trust (or not trust) me on that.

So no lessons learned?
Did you reply to the wrong comment?

I think asking questions is ideal. Even when I'm 99% sure a line is blatantly wrong, I will ask something like, "What is this for?". Maybe I missed something - wouldn't be the first time.

Darepublic originally posted his coworker’s code to make fun of above.