Each item in the input array is a string, but when using the default converter, they're always JSON strings representing marshalled golang values. It would be nice if the web UI didn't show this raw JSON string full of backslashes and instead converted it to a nested object.
Caveat: ambiguity, limitations of JS number precision
This visual representation is potentially ambiguous or inaccurate if using a custom converter. The web UI would have to speculatively attempt to parse each item in the inputs array as JSON and, if parsing succeeds, swap it out. But if parsing fails, leave it as-is.
If I was using a custom converter which spat out strings, and I always wanted those strings to be represented in the UI as raw strings, then the speculative approach above could occasionally fail. If a string was coincidentally valid JSON (say, a massive integer that exceeds the capacity of JavaScript numbers, something like "123456789123456789123456789123456789") then it might be parsed to a JavaScript number, lose precision, and be represented incorrectly.
To avoid this, the UI can merely validate that the string is valid JSON, but then render it without the backslash-escapes, adding newlines and indentation to pretty-print it. This avoids the conversion to and from JavaScript values.
Each item in the
inputarray is a string, but when using the default converter, they're always JSON strings representing marshalled golang values. It would be nice if the web UI didn't show this raw JSON string full of backslashes and instead converted it to a nested object.Instead of this:
This:
Caveat: ambiguity, limitations of JS number precision
This visual representation is potentially ambiguous or inaccurate if using a custom converter. The web UI would have to speculatively attempt to parse each item in the
inputsarray as JSON and, if parsing succeeds, swap it out. But if parsing fails, leave it as-is.If I was using a custom converter which spat out strings, and I always wanted those strings to be represented in the UI as raw strings, then the speculative approach above could occasionally fail. If a string was coincidentally valid JSON (say, a massive integer that exceeds the capacity of JavaScript numbers, something like "123456789123456789123456789123456789") then it might be parsed to a JavaScript number, lose precision, and be represented incorrectly.
To avoid this, the UI can merely validate that the string is valid JSON, but then render it without the backslash-escapes, adding newlines and indentation to pretty-print it. This avoids the conversion to and from JavaScript values.