[Feature Request]: Support virtualization

[TrevorBurnham]

Description

Currently, if you render a CodeView with a large amount of code (say, 10,000 lines of JSON), the browser will be stuck for a noticeable period of time because CodeView renders and highlights all of that code at once.

The underlying ace-code library supports virtualization (rendering only the code that's actually visible to the user) but CodeView doesn't.

I asked Copilot about this and got this response:

Here’s how the current CodeView differs from relying on Ace’s incremental/virtual rendering, with direct references:

• In src/code-view/internal.tsx the component tokenizes and renders the entire code block eagerly into React nodes:

• It splits the entire content string into lines and builds React elements for every line (textHighlight), or calls the provided highlight function to do the same.

• See lines 18–32: textHighlight splits code into lines and wraps each line in a <span> with a newline appended.

• Then it wraps those nodes in a fragment and extracts them as a single React element (codeElement), lines 53–58.

• Finally, it maps over every child to render a <tr> for each line (lines 90–118), producing the full table up front.

• This means the entire content is in the DOM at once and fully tokenized before render, which defeats virtualization. Ace’s normal renderer would keep the session text and only paint the visible rows; here, React is asked to create DOM for all rows every time.

• The scroll-container (<div className={styles["scroll-container"]}> at line 69) wraps a static <table> of all lines; there’s no hook into Ace’s row windowing or renderer. So the browser ends up with one row per line regardless of viewport.

In short, today’s CodeView precomputes and mounts every line (and every highlight token if a custom highlight is used). To use Ace’s virtualization, the component would need to hand the text to Ace and let Ace’s renderer manage which rows to paint, instead of building the entire table of lines in React.

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues on this and main repositories for duplicate requests

[TrevorBurnham]

I put together a WIP branch for this: https://github.com/TrevorBurnham/code-view/tree/virtualize It works by using ace-code to only render the visible "slice" of code as the user scrolls.

Unfortunately, it doesn't work as smoothly as I'd hoped. It does have benefits: Without virtualization, the 10,000-line demo uses >1GB of memory and is liable to crash the browser tab; with virtualization, that same demo uses ~500MB of memory and is more stable, but scrolling is still awkward, with a noticeable lag between scrolling and rendering if you scroll quickly.

If someone wants to take this and run with it, I'm sure they could find a better solution, perhaps by making better use of ace-code's own internal virtualization capabilities.

[just-boris]

I will not be involved in the final decision regarding this contribution, but here are my couple cents.

Originally, code view component was designed as simple as "Box with a few custom styles". This change adds extra bundled code for customers, even if they don't use the feature.

If I were to build this feature, I would probably go with a custom component. Because this component lives in a separate package, all necessary design tokens are already exported from the tokens package