Switch from Tree to JSON -> "An error was caught while rendering the AST. This usually is an issue with astexplorer itself."

[TiberiumFusion]

Describe the bug
Switching from Tree to JSON tab results in this message:
"An error was caught while rendering the AST. This usually is an issue with astexplorer itself. Have a look at the console for more information. Consider filing a bug report, but check first if one doesn"t already exist. Thank you!"

The message told me to file a bug report, so I am.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://astexplorer.net/
2. Select @babel/parser
3. Paste provided sample javascript in left side panel:
   crash demo.js.txt
4. Wait for parse and right side panel to update
   Observe Tree panel is working properly (afaik) and is navigable
5. Switch from Tree to JSON tab
   "An error was caught while rendering the AST."
6. Switch back from JSON tab to Tree
   "An error was caught while rendering the AST."
7. Type some new javascript into left panel.
   Observe right side panel is functional again. Both the Tree and JSON tabs work.

Expected behavior
Json string appears when JSON tab is clicked when using provided sample javascript.

Browser (please complete the following information):

• Chromium 122.0.6261.85 on Windows

astexplorer settings:

• Selected parser: @babel/parser
• Selected transformer (if applicable): n/a

---

Using other parsers:

• acorn: JSON tab works
• typescript: JSON tab broken

Other notes

The sample javascript provided is not mine and I cannot guarantee it is free of errors. If some parsers are choking on this sample javascript while others can handle it, then a detection and message explaining this to the user could be helpful.

[Scipion]

In the console in Chrome/Chromium you can see is not a parser error:

In Firefox would just crash your tab.

the file is 58k lines code transformed in who knows how many megs object, so it's kind of understandable that the browser crashes parsing some hundreds of Megs object into a string that exceeds size limit.

Actually there is a test to test that kind of error: https://source.chromium.org/chromium/chromium/src/+/main:v8/test/mjsunit/json2.js;l=130?q=%22Invalid%20string%20length%22&ss=chromium&start=201

The error could be manage differently, but I don't think it's not a bug and can be close.

[TiberiumFusion]

@Scipion

If the browser-provided JSON library is incapable of performing this task, then I suggest a more capable replacement be used instead. Perhaps the solution is as simple as a streaming JSON stringify implementation which outputs to a file stream or an array of strings under the V8 string length limit.

And if this is indeed the source of the error, then I would agree this is not a bug. It is a flaw instead.

The sample javascript I produced which produces this error in astexplorer is not especially massive. There are other webpack-reliant websites which employ monstrous, single javascript files that are even larger than that sample. Working with these files in a timely fashion requires tools like astexplorer, so it is unfortunate that this component of astexplorer cannot handle this type of javascript found in the wild.

Should this issue be closed without resolution?

• Your comment did not magically make the JSON tab start working for me. It is still broken, right now. Therefore, this issue is not resolved, so I will not close it myself until the problem is fixed.
• If an administrator decides this issue shall not be addressed and closed as an admission of that, then at the very least close it as not planned. This issue is documentation of an astexplorer limitation. Closing it as "resolved" without resolving anything suggests to the reader of the issues tab that the issue was a hoax or lie. I mention this because I see the administrators of this project have closed every issue as "resolved" and never used "not planned".

In case this issue is closed without resolution, does anyone here know of a graphical AST explorer tool that does not have this limitation? The others I have found through Google are orders of magnitude slower than astexplorer and nigh unusable as a result.

Non sequitur: that obfuscated console trace from the bastardized js is not a clear statement of "not a parser error". How do you know that functions Ci zg fi Ti Qj Kj yj cg fg gg Ga and gd are not part of the parser library? How am I supposed to know that as a reader? I don't have time to replicate your debugging environment and inspect each obfuscated function. Now, I will admit that the offending JSON.stringify call has a high likelihood to originate from astexplorer itself, but that hideous & unusable trace message alone is not conclusive evidence.

[Scipion]

Right, if the string length limit is reached a possibility is to give the option of downloading the json file. Feel free of send a pull request with that feature :)

If you can find the time to replicate the environment I'll gladly lend you a hand.