[liontwist]

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.

[bryanrasmussen]

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. }

[accoil]

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.

[bryanrasmussen]

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.

[accoil]

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.

[bryanrasmussen]

probably some times the api comes out with an empty string.

[darepublic]

The code is either going to loop once and exit or loop forever no

[andrewf]

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.

[accoil]

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)

[liontwist]

Now two of you are misunderstanding.

It’s applying the operation recursively.

[darepublic]

Why the while loop

[otabdeveloper4]

Because some upstream idiot is calling JSON.stringify several times.

[accoil]

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.

[liontwist]

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.

[darepublic]

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.

[liontwist]

So no lessons learned?

[digging]

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.

[liontwist]

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