Replace custom HTML with a JSON view

[rajeev]

In one of my nodes, there's a huge amount of JSON formatted data returned by an API (about 600KB of data, including several base64 encoded images). Along with all of the other nodes in my spur, this causes the entire frontend to be extremely slow, or even freeze, after the workflow is run and all the outputs are rendered.

After replacing with this JSONView, the performance is far better.

I don't have any benchmarks or anything for this, so feel free to reject it. I just thought it might be useful in general.

---

Important

Replaces custom HTML with JsonView in NodeOutputDisplay.tsx to improve performance for large JSON data.

• Behavior:
  • Replaces custom HTML rendering with JsonView in NodeOutputDisplay.tsx for JSON data.
  • Improves performance for large JSON data sets, such as those with base64 images.
• Imports:
  • Adds JsonView and its CSS from react18-json-view.
• Misc:
  • Removes custom HTML and button logic for JSON rendering in renderJsonObject().

^{This description was created by for 72d3550. It will automatically update as commits are pushed.}

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 72d3550 in 1 minute and 21 seconds

More details

• Looked at 47 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 4 drafted comments based on config settings.

1. frontend/src/components/nodes/NodeOutputDisplay.tsx:148

• Draft comment:
  The custom per-key copy-to-clipboard functionality has been removed. Ensure this change is intended and consider if users still need the ability to copy individual JSON entries.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
  The comment is about a real change in functionality - we did remove the per-key copy feature. However, the comment is phrased as "ensure this change is intended" which violates our rule about not asking authors to verify their intentions. The comment also doesn't definitively state that this is a problem, just speculates about whether users need this feature.
  The functionality change is real and could impact users. Maybe this is an important enough UX regression that we should keep the comment despite its speculative phrasing?
  While the functionality change is real, our rules are clear that we should not make speculative comments or ask authors to verify their intentions. If the removal of this feature was definitely a problem, the comment should state that directly.
  Delete this comment. While it identifies a real change, the speculative phrasing and request for verification violate our commenting rules. If the feature removal is truly problematic, it should be raised as a direct issue rather than a speculative question.

2. frontend/src/components/nodes/NodeOutputDisplay.tsx:7

• Draft comment:
  Importing CSS from 'react18-json-view/src/style.css' might break package encapsulation; verify if a standard CSS import is available.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  This seems like a speculative comment. The package explicitly provides this CSS file path in its documentation, and importing CSS files from node_modules is a standard practice. The comment isn't pointing to a clear issue, just suggesting to "verify" something that's likely already correct.
  The comment could be valid if there's a documented best practice for this specific package that recommends a different import path. Maybe there are encapsulation issues I'm not seeing.
  Looking at the package and common React practices, importing CSS directly from node_modules is normal and the path seems intentionally exposed. Without clear evidence of a problem, this is just speculation.
  Delete the comment as it's speculative and asks for verification without pointing to a clear issue. The current import follows standard practices.

3. frontend/src/components/nodes/NodeOutputDisplay.tsx:148

• Draft comment:
  Using simplifies JSON rendering, which is great. Consider checking if the library supports default collapsed nodes or other performance options for very large JSON data.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The comment is speculative - it suggests checking for features that may or may not exist. It's not pointing out a clear issue, just suggesting to look into potential optimizations. The comment also asks the author to verify/check something rather than making a concrete suggestion. Per the rules, we should avoid speculative comments and comments that ask authors to check things.
  The performance concern could be valid if there are known issues with large JSON data. The previous implementation had a simple recursive render which could also have performance issues.
  While performance is important, the comment doesn't provide clear evidence of an actual problem or specific solution. It's the kind of speculative "what if" comment we want to avoid.
  Delete this comment as it is speculative and asks the author to check/verify something rather than pointing out a clear issue that needs fixing.

4. frontend/src/components/nodes/NodeOutputDisplay.tsx:7

• Draft comment:
  Ensure that the new dependency 'react18-json-view' is added to package.json and its version is locked appropriately.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

Workflow ID: wflow_grAhUEl8S9reXn6u

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[JeanKaddour]

Thank you very much! We'll take a look