[kalvinnchau]

Problem

Each keystroke in the rich composer runs several passes over the draft: the input filter, the normalizer, the render, the decorations and the selection handlers. Each pass projected the ProseMirror document into a draft again, and each read of the saved snapshot ran a schema parse again. Decorations also re-scanned the whole draft for #channel and agent references on every pass, the emoji shortcode set was rebuilt on every render, and emoji sizing built that set even for drafts without a :. The work grows with the draft and runs several times per key.

Change

• projectComposerDocument is memoized per document (a WeakMap on the immutable ProseMirror doc), and readComposerSnapshot per snapshot object. The passes of one key share a single projection and parse. EditableInput drops its own per-view projection cache, which this replaces.
• decorationsFor keeps the last messageReferences result and reuses it while the text, profiles, channels and agents are the same objects.
• The emoji shortcode set is built once per renderable emoji catalog (useMemo), and emoji sizing returns early when the draft has no :.

No behavior changes

The projection reads only the document and the fixed schema, and the snapshot parse reads only the snapshot, so both caches return what a fresh call would. The reference cache is keyed on every input the scan reads, so a channel that is added, renamed or archived misses the cache. A new test checks that a channel arriving or leaving updates the reference decoration. Sizing a draft without a : was already a no-op, because only :shortcode: is replaced.

Evidence

Bench: type one character at the end of a draft in a mounted RichComposerInput (jsdom), with 2,000 channels and 1,000 custom emoji. Drafts are prose with links, of 200, 3,000 and 10,000 characters; the last row adds a #channel and a :shortcode: every 30 words. Medians per key, stock and this PR interleaved on a Linux and a macOS workstation.

draft	Linux: stock	Linux: this PR	Linux Δ %	macOS: stock	macOS: this PR	macOS Δ %
200 chars	0.88 ms	0.72 ms	−18.4%	0.62 ms	0.39 ms	−37.3%
3,000 chars	2.59 ms	2.44 ms	−5.7%	1.42 ms	1.35 ms	−4.8%
10,000 chars	7.09 ms	6.69 ms	−5.6%	3.97 ms	3.78 ms	−4.8%
3,000 chars with references	6.21 ms	4.69 ms	−24.4%	3.88 ms	2.82 ms	−27.2%

Lower is better. There are 8 samples per cell. These are jsdom timings without CPU throttling, so they exclude layout and paint; long plain drafts are dominated by work this PR does not touch.

Checks: the composer unit suites pass (EditableInput, RichComposerInput, composer-document, emoji-size, mention-draft), along with tsc and biome.

🤖 Generated with Claude Code