Skip to content

feat(superdoc): expose pendingSelection on the pending comments-update event (SD-3323)#3578

Open
caio-pizzol wants to merge 1 commit into
mainfrom
caio/sd-3323-expose-the-pending-selection-on-the-pending-comment-event
Open

feat(superdoc): expose pendingSelection on the pending comments-update event (SD-3323)#3578
caio-pizzol wants to merge 1 commit into
mainfrom
caio/sd-3323-expose-the-pending-selection-on-the-pending-comment-event

Conversation

@caio-pizzol
Copy link
Copy Markdown
Contributor

The pending comments-update event now carries pendingSelection — the Document API selection snapshot taken before insertComment('pending') runs. A consumer building a custom comment composer previously had to track the selection continuously (stashing the latest non-empty snapshot) because by the time the pending event fired the live DOM selection was gone. Now they read it straight off the event.

ui.comments.createFromCapture's input is widened to CommentAnchorCapture (anything carrying a target), so the event's SelectionInfo forwards directly:

superdoc.on('comments-update', (e) => {
  if (e.type === 'pending' && e.pendingSelection?.target) {
    ui.comments.createFromCapture(e.pendingSelection, { text });
  }
});

The field is typed SelectionInfo, not SelectionCapture — that's what the snapshot actually is (target/text, not the controller-derived selectionTarget/quotedText). createFromCapture only reads target, so a full SelectionCapture isn't needed and we avoid duplicating the UI-controller's selectionTarget derivation in the store.

Review: the field name + SelectionInfo type (vs forcing a full SelectionCapture), and the createFromCapture input widening to CommentAnchorCapture (newly exported from super-editor/ui and superdoc/ui).
Verified: comments-store.test.js → 115 passed; comments.test.ts → 22 passed; check:public:superdoc → 13/13 stages PASS; manual dev-app smoke → pending event carries pendingSelection.target before the pending mark is inserted.

@caio-pizzol caio-pizzol requested a review from a team as a code owner May 29, 2026 19:57
@linear-code
Copy link
Copy Markdown

linear-code Bot commented May 29, 2026

SD-3323

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0821ee78a3

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

// `target`); consumers forward it to `ui.comments.createFromCapture`
// instead of tracking the selection themselves. `null` when there's
// no addressable selection or no active editor.
const pendingSelection = superdoc.activeEditor?.doc?.selection?.current?.({ includeText: true }) ?? null;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Gate pendingSelection to SuperEditor selections

When the comment tool is invoked from a PDF selection (activeSelection.source === 'pdf' in the shared toolbar flow), superdoc.activeEditor can still point at a DOCX editor, so this call captures that editor's stale Document API selection and emits it as pendingSelection for the PDF pending comment. Consumers following the new guidance and passing that payload to ui.comments.createFromCapture would then create/anchor a DOCX comment instead of treating the PDF comment as having no Document API text target; gate this snapshot on the active selection/source (or document id) and emit null outside SuperEditor text selections.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cubic analysis

No issues found across 8 files

Linked issue analysis

Linked issue: SD-3323: Expose the pending selection on the pending comment event

Status Acceptance criteria Notes
Emit the 'comments-update' pending event with a pendingSelection payload (Document API SelectionInfo | null). The store now attaches pendingSelection to the pending event and the core types include a pendingSelection field typed as SelectionInfo | null.
Capture pendingSelection before inserting the pending mark (so the snapshot reflects the pre-mutation selection). Selection snapshot is taken prior to calling insertComment and tests assert the pending event is emitted before the pending mark insertion.
Allow ui.comments.createFromCapture to accept the pending event's SelectionInfo shape (i.e., a CommentAnchorCapture with target) without requiring a cast, and forward the target to comments.create. The createFromCapture signature was widened to accept CommentAnchorCapture and a unit test verifies passing a SelectionInfo-shaped object works and forwards the target to the underlying create call.
Export the new CommentAnchorCapture type from the public UI surface so consumers can rely on it. The CommentAnchorCapture type was added and exported from the UI index/public files.

Tip: cubic could auto-approve low-risk PRs like this, if it thinks it's safe to merge. Learn more

Re-trigger cubic

…e event (SD-3323)

The pending comments-update event now carries pendingSelection, the Document API selection snapshot captured before insertComment('pending') clears the live DOM selection. Consumers building a custom comment composer can forward it straight to ui.comments.createFromCapture instead of continuously tracking the selection ahead of the floating-bubble click.

createFromCapture's input is widened to CommentAnchorCapture (anything carrying a target), so the SelectionInfo on the event passes directly without reconstructing a full SelectionCapture. The field is typed SelectionInfo (not SelectionCapture) since that is what the snapshot actually is.

Related to IT-1113.
@caio-pizzol caio-pizzol force-pushed the caio/sd-3323-expose-the-pending-selection-on-the-pending-comment-event branch from 0821ee7 to 845fbfd Compare May 29, 2026 20:07
@codecov-commenter
Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants