Virtualization Roadmap

[zbeyens]

Disclaimer: AI-generated

Below is a practical, incremental roadmap you could follow to integrate virtualization into a fork of slate-react. The overall theme is to start small (read‐only, minimal selection) and progressively add features from simple to complex, each time ensuring you have a “production-usable slice.”

---

0. Fork PlateStatic into PlateStaticVirtual

Since PlateStatic is read-only by design, we’ll start by adding virtualization there:

1. Create a new PlateStaticVirtual.tsx from PlateStatic.tsx.
2. Integrate a virtualization library (e.g. react-window or react-virtualized) in place of <Children>.
3. Implement minimal logic to flatten your top-level nodes so each one is rendered in a virtual “row.”
4. Remove or comment out advanced placeholders or selection logic if it complicates initial testing—since it’s read-only you can skip a lot.

Goal:

• A “drop-in” <PlateStaticVirtual/> that can handle thousands of nodes in read-only mode with good performance.
• Maintains production stability for read-only usage.

---

1. Fork and Simplify (Read-only + Single-Block)

Goal: A fork of slate-react that only displays static (non-editable) content, with a single top-level block per line, using virtualization for rendering.

• Remove or disable all editing logic, events, composition handling, etc.
• Keep the core logic for rendering Slate nodes (<Element>, <Text>), but do not attach selection or input event handlers.
• Integrate your virtual list (e.g., virtua) in place of the standard “recursive children” logic.

Milestone:

• You can show a large read-only document in Slate format, using virtualization behind the scenes.
• In production, this is already useful for “read-only” document viewers: extremely fast to load and scroll large docs.

---

2. Expand to Multi-Block + Basic Scrolling

Goal: Support nested blocks and multiple levels in the read-only tree, still with virtualization.

• Preserve the simpler “render each block at top-level,” but also handle nested lists or nested blocks—some of which you may also want to virtualize.
• Possibly overscan each block’s children (or nest another <VList> for deeply nested structures).
• Keep it read-only: no text input, no composition.

Milestone:

• A robust multi-level read-only slate doc, with partial virtualization at each level if needed.
• Production users can view big hierarchical docs quickly.

---

3. (Optional) Minimal Single-Block Selection

Goal: Let the user highlight text with the mouse and see the highlight, but keep the doc read-only.

• Implement or preserve only the minimal selection logic in slate-react.
• Possibly only allow selection inside a single block to simplify.
• Don’t worry about multi-block selection or composition.

Challenges:

• If the user selects text in block # 50, that block must be in the DOM. If you scroll away, do you keep it mounted so the highlight stays visible? This is an early taste of the complexities of “virtualized selection.”

Milestone:

• The user can “drag select” text in the currently visible block(s), see the highlight, and can copy.
• This is enough for simple “copy/paste from read-only” use-cases.

---

4. Full Multi-Block Selection (Still Read-only)

Goal: Let the user select text across multiple blocks.

• Overscan or “force render” the blocks in the selection range so highlight is fully displayed.
• If the user does Cmd+A, do you show all blocks highlighted or just a partial “some blocks are selected but not rendered”? (You decide based on performance vs user expectations.)

Milestone:

• Now the doc is read-only but fully functional in terms of “select all, highlight from block # 1 to block # 100, and copy.”
• Production users can read large docs and highlight across blocks.

---

5. Add Basic Editing in One Block at a Time

Goal: Introduce text input for a single block, but no multi-block editing.

• Re-enable minimal onBeforeInput, onInput, composition logic for just one “active” block.
• Possibly keep other blocks read-only.
• If the user clicks into block # 50 to edit, you force mount that block if it’s not already mounted, and you handle composition in it.
• Avoid complicated multi-block merges or splits.

Milestone:

• A partially editable doc: user can see large read-only content, can “click to edit” one block, type text, etc.
• This incremental step is less complex than doing full multi-block merges, “Enter to create new paragraphs,” etc.

---

6. Full Multi-Block Editing (Basic Features)

Goal: Expand from one-block editing to typical multi-block editing.

• Re-enable the rest of Slate’s editing logic (splitting blocks on Enter, merging blocks on Backspace, etc.).
• This is where “virtualized selection for multi-block editing” can get tricky:
  • If the user splits at the end of block # 49, block # 50 moves. You need to ensure the block’s path updates do not break.
  • Possibly rely on standard Slate path update logic, but keep in mind that unrendered blocks still exist in memory.

Milestone:

• Multi-block editing works. We still might skip advanced features (tables, nested blocks, DnD, plugin architectures).
• Production users can do typical text editing across large docs with the performance benefits of virtualization.

---

7. Edge Cases & Advanced Features

Potential “stretch” tasks:

• Tables: Virtualizing large tables might mean row & column virtualization.
• Images, Media: If an image is scrolled out, do we unload it?
• Plugins: Many Slate plugins assume the entire DOM is present. Some rewriting might be needed.
• Mobile / IME: Composition events on mobile can be finicky with virtualization. You’ll probably overscan or force keep the block in the DOM while composing.

---

Recommended Dev Strategy

1. Create a Fork

   • Strip out all advanced logic from slate-react except the rendering pipeline and a minimal read-only flow.
   • Start a “virtual-slate-react” or “slate-react-virtual” codebase.

2. Iterate with Clear Milestones

   • Each milestone aims to produce something usable in production.
   • Deploy or release a minor version at each step so integrators can test:
     1. M1: Read-only, single-level.
     2. M2: Read-only, multi-level.
     3. M3: Single-block selection.
     4. M4: Multi-block selection, read-only.
     5. M5: Single-block editing.
     6. M6: Multi-block editing.
     7. And beyond…

3. Focus on Test Coverage

   • For each milestone, write integration tests to ensure you handle scrolling, selection, or composition.
   • Keep a suite of large docs to verify performance.

4. Start Minimal:

   • Possibly skip advanced features (tables, nested objects) until you have the basics stable.
   • The power of Slate is that you can add them later once the fundamental “virtualized doc” engine is stable.

5. Push to Production in Steps

   • After milestone 1 & 2, you already have a workable read-only viewer (maybe 80% of use cases?).
   • Then, methodically add editing capabilities.

[YunshengLu]

I am trying to use Virtualization to optimize large text, but recently when I was browsing the PR of slatejs, I found that @12joan optimized the rendering by Experimental chunking optimisation and other performance improvements. Will paltejs follow up on this experimental feature? This will determine whether I will continue to try to use Virtualization.

[12joan]

I'll be working on enabling chunking in Plate shortly after it releases in Slate.

Personally, I wouldn't recommend pursuing virtualisation unless you have no alternative, since it causes a large number of unavoidable UX and accessibility issues.

[YunshengLu]

I'll be working on enabling chunking in Plate shortly after it releases in Slate.

Personally, I wouldn't recommend pursuing virtualisation unless you have no alternative, since it causes a large number of unavoidable UX and accessibility issues.

Thanks for your reply, looking forward to seeing this feature in Plate

[dpnova]

are those issues mentioned in the slate PR @12joan ? would be interesting to circulate with my team

[12joan]

@dpnova The Slate PR is unrelated to virtualisation, although it does contain instructions on enabling the content-visibility: auto CSS rule on each chunk, which is similar to virtualisation in a way.

The main issues I know of with virtualisation in a text editor relate to command+a, command+f, and allowing screen readers to read content that's off-screen. I wouldn't recommend any virtualisation solution that doesn't take those things into account.

To be clear, the changes in the Slate PR have none of these issues.

[dpnova]

ahh I conflated the two approaches.. thanks!