extract reusable functions from plainTextView

[daesunp]

Description

Extracts reusable functions from plainTextView for shared use in our example app, and boards.

[github-actions]

Hi! Thank you for opening this PR. Want me to review it?

Based on the diff (628 lines, 6 files), I've queued these reviewers:

• Correctness — logic errors, race conditions, lifecycle issues
• Security — vulnerabilities, secret exposure, injection
• API Compatibility — breaking changes, release tags, type design
• Performance — algorithmic regressions, memory leaks
• Testing — coverage gaps, hollow tests

How this works

• Adjust the reviewer set by ticking/unticking boxes above. Reviewer toggles alone don't trigger anything.

• Tick Start review below to dispatch the review fleet.

• After review finishes, tick Start review again to request another run — it auto-resets after each dispatch.

• This comment updates as new commits land; your reviewer selections are preserved.

• Start review

[Copilot]

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

[Josmithr]

This isn't really what I'd been imagining. While the 2-way binding could be convenient for some cases, I'm not sure how universally applicable it will be. The caveats called out in the remarks below seem to support this concern.

My assumption is that we would just have a simple 1-way sync from tree -> string. This is simple, and I would think pretty generally applicable. I.e., something like:

Usage:

const { text, selection } = useTreeSynchronizedString(tree, initialSelection);

Implementation:

function useTreeSynchronizedString(tree: TextAsTree.Tree, initialSelection?: SelectionRange): {
	text: string,
	selection: SelectionRange | undefined
} : {
	// useEffect block that binds character-change listener and recomputes `text` and `selection` any time the text tree changes
	// I think this mostly just amounts to calling `applyTextOps` on any change
}

The app author is still responsible for providing the mapping in the other direction.

I think this would be a lot less complex. And an application author that wants to do something like what you've built below could easily use our code as reference / a starting place to create such a utility. But I worry that this code is simultaneously complex and may or may not be widely applicable.

What do you think? I am curious what led you to this larger scope - I could easily be missing something here.

[daesunp]

I started with a smaller scope, but kept expanding it to optimize for "ease of use" for the boards prototype, and ended up basically re-wrapping our existing example without noticing. Your suggestion makes a lot more sense, and I updated with your suggestions :)

[github-actions]

Bundle size comparison

Base commit: 3adb358594a36333b40463a2f8be3abcb07c782c
Head commit: b1ee35a35661d7b5550b804560f1f814c27f8d8f

⚠️ Comparison unavailable.

The PR's CI build failed — fix the build and the comment will update once the next run succeeds.