docs/plans/2026-04-11-slate-v2-react-perfect-runtime-opti-plan.md
Make the slate-v2 rewrite earn the “React-perfect runtime” claim honestly.
That means:
The current situation is blunt:
5000 and 10000 blocksSo the next work is not:
The next work is:
Do not do these in this plan:
slate-batch-engineFrom api-drift-perf-scoreboard.md:
From 2026-04-10-slate-v2-core-perf-batch.md:
134.20ms -> 3.08ms1779.73ms -> 10.36ms5000 blocks is still bad:
370.97ms -> 348.03ms368.58ms -> 297.34ms5000 blocks is still bad:
editor.children.length 940.18ms -> 784.01msEditor.nodes(...) 1275.18ms -> 796.95msEditor.positions(...) 1013.11ms -> 693.64msMeasured separately:
5000 and 10000 blocks, legacy chunking still wins hard on typingThat means:
Most likely remaining wall:
If this stays bad, React cannot save it.
Still ugly:
editor.childrenEditor.nodes(...)Editor.positions(...)This matters because the React-perfect runtime depends on cheap committed reads and narrow subscriptions. If core reads are gross, selectors become expensive too.
This is the layer the rewrite is supposed to win on:
But this layer only matters after Tier 1 and Tier 2 stop poisoning it.
The optimization program should run in this order:
Anything else is backwards.
Goal:
Required artifacts:
pnpm bench:replacement:huge-document:chunking:compare:localWork:
slate-v2/scripts/.tmp/Acceptance:
Goal:
Why first:
Likely files:
Required ideas to evaluate:
insert_text / remove_textcreateDraftTree(...) on every outer opGuardrails:
Acceptance:
Goal:
Likely files:
Work:
Editor.nodes(...) and Editor.positions(...) honestly lazy only after
measuring a design that preserves current behaviorGuardrails:
Acceptance:
Goal:
Reference:
Work:
useSyncExternalStore selector-firstLikely lanes:
#5131-style selection subscription breadth#3656-style leaf rerender breadth#4141-style ancestor rerender breadthAcceptance:
Goal:
Reference:
Work:
<Activity> / hidden-tree posture where it helpsAcceptance:
5000 and 10000 is no longer badly behind legacy
chunkingFor every phase:
slate package testsDo not claim a win without:
Hard no:
When an optimization regresses contract behavior:
The rewrite says it wants a React-perfect runtime.
Right now the harsh truth is:
So stop pretending the next move is another cute hook or another normalization rule.
The next move is boring, deep engine work:
If the core keeps rebuilding too much state per keystroke, the React-perfect runtime is just branding.
This program is done when all of these are true: