feat(examples): vanilla custom UI comments example (SD-2929)#3130
Closed
caio-pizzol wants to merge 1 commit intocaio/sd-2929-vanilla-custom-ui-toolbarfrom
Closed
feat(examples): vanilla custom UI comments example (SD-2929)#3130caio-pizzol wants to merge 1 commit intocaio/sd-2929-vanilla-custom-ui-toolbarfrom
caio-pizzol wants to merge 1 commit intocaio/sd-2929-vanilla-custom-ui-toolbarfrom
Conversation
77021d4 to
6af174a
Compare
8267653 to
567d5db
Compare
Second focused minimal example under examples/editor/custom-ui/.
Single file (~125 lines) demonstrating the comments composer pattern
that the controller surfaces specifically solve:
- ui.selection.capture() freezes the selection at the moment the
composer opens. The textarea then takes focus and the editor's
live selection visually clears, but the captured snapshot still
has the original anchor.
- ui.comments.createFromCapture(capture, { text }) anchors the new
comment against that snapshot, not the live (now empty)
selection. A composer that read the live selection at submit
time would refuse the create.
- ui.comments.observe(snapshot => ...) renders the sidebar list
from a single subscription.
- ui.comments.resolve / .reopen / .reply route through the same
Document API that powers DOCX import / export, so changes here
round-trip through Word.
- ui.createScope() collects every subscription so the whole surface
tears down cleanly on ui.destroy().
Wired into examples/manifest.json and the custom-ui CI smoke matrix.
Stacked on caio/sd-2929-vanilla-custom-ui-toolbar.
6af174a to
a448478
Compare
Contributor
Author
|
Closing this for now after the Custom UI examples audit. We're going to keep examples docs-driven and concept-shaped, not surface-shaped. The next Custom UI examples should be focused vanilla examples linked from specific docs pages: The |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second focused minimal example under `examples/editor/custom-ui/`. Single file (~125 lines) demonstrating the comments composer pattern that the controller surfaces specifically solve.
The load-bearing piece is `ui.selection.capture()`: the user clicks "Add comment", the textarea takes focus, the editor's live selection visually clears. A composer that read the live selection at submit time would refuse the create. `capture()` returns a frozen snapshot at composer-open time, and `ui.comments.createFromCapture(capture, { text })` anchors against that snapshot regardless of where focus has moved.
The list renders from `ui.comments.observe(snapshot => ...)`: one subscription, plain DOM. Resolve / reopen / reply route through `ui.comments.*` and end up in the same Document API that powers DOCX import/export, so changes here round-trip through Word.
Verified: `pnpm --filter superdoc build` clean; `tsc --noEmit` clean in the new example.