Performance Issues with Large Payloads – Virtualization Support?

[aneuwald-ctw]

Hello there,

I'm a developer at Lichtblick (https://github.com/Lichtblick-Suite/lichtblick), and we're currently using react-tree-json within our Raw Messages Panel to inspect and navigate through full JSON message structures.

One issue we've encountered is related to rendering performance when dealing with large payloads. In cases where the message is particularly big (e.g., deeply nested or with many entries), the panel becomes noticeably sluggish—sometimes to the point of blocking the UI and degrading the responsiveness of the entire application.

We're wondering if there's any ongoing work or planned support for virtualization within the component—something that could prevent the tree from rendering or computing nodes that aren't currently visible in the viewport. We believe this could significantly improve performance, especially for large datasets.

Would love to hear your thoughts or suggestions on potential workarounds or contributions we could make in this direction.

Thanks in advance!

Cheers,
Alex

[gtk-grafana]

@aneuwald-ctw I'm not a maintainer of this package, so take this with a grain of salt, but this package's implementation focuses on "pagination" for performance rather then virtualization, i.e. not rendering all nodes by default, and allowing implementers to dynamically set which nodes get visualized.

Virtualizing would require measuring the count and height of all nested nodes, which is difficult without breaking existing functionality, especially since this package supports wrapping text by default.

Also this package doesn't get a lot of activity, so I wouldn't expect the maintainers to drop the 40+ hours implementing virtualization.

I might recommend forking this package and disabling wrapping text for a virtualization proof of concept and potentially proposing pushing those changes to the base repo, but since this package does such an excellent job with "pagination" as a solution for rendering large JSON documents I would assume the maintainers wouldn't want to support that use-case which is diametrically opposed to the performance strategy currently used.