Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughBoth StyleManager.createLink and LinkToolbar.editLink now avoid replacing link text when the provided text equals the document's existing text; they read existing text with tr.doc.textBetween(...) and call tr.insertText(...) only if different, while still applying the link mark over the target range. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
nperez0111
left a comment
There was a problem hiding this comment.
I'm okay with this as a stop-gap solution for right now, only because it is so simple. But, I would want more out of this later. But, that would come at the cost of higher complexity in comments. Let's just fix the user-facing issue for now
0490e5d to
b89283f
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/core/src/extensions/LinkToolbar/LinkToolbar.ts (1)
92-95: Consider extracting shared link-text replacement logic.This same guard now exists in both
LinkToolbarExtension.editLinkandStyleManager.createLink; a shared helper would reduce behavior drift risk over time.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/extensions/LinkToolbar/LinkToolbar.ts` around lines 92 - 95, There is duplicated guard logic that compares textBetween(...) and only calls tr.insertText(...) found in LinkToolbarExtension.editLink and StyleManager.createLink; extract this into a shared helper (e.g., replaceLinkTextIfDifferent(tr, range, text) or LinkUtils.replaceTextIfDifferent) and replace both implementations to call that helper so the equality check and insertion live in one place and behavior stays consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/core/src/extensions/LinkToolbar/LinkToolbar.ts`:
- Around line 92-95: There is duplicated guard logic that compares
textBetween(...) and only calls tr.insertText(...) found in
LinkToolbarExtension.editLink and StyleManager.createLink; extract this into a
shared helper (e.g., replaceLinkTextIfDifferent(tr, range, text) or
LinkUtils.replaceTextIfDifferent) and replace both implementations to call that
helper so the equality check and insertion live in one place and behavior stays
consistent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 95806b06-0205-4cbc-a64f-060e399caae7
📒 Files selected for processing (2)
packages/core/src/editor/managers/StyleManager.tspackages/core/src/extensions/LinkToolbar/LinkToolbar.ts
@blocknote/ariakit
@blocknote/code-block
@blocknote/core
@blocknote/mantine
@blocknote/react
@blocknote/server-util
@blocknote/shadcn
@blocknote/xl-ai
@blocknote/xl-docx-exporter
@blocknote/xl-email-exporter
@blocknote/xl-multi-column
@blocknote/xl-odt-exporter
@blocknote/xl-pdf-exporter
commit: |
| return; | ||
| } | ||
| tr.insertText(text, range.from, range.to); | ||
|
|
There was a problem hiding this comment.
should actually probably use style manager.createLink here no?
|
@matthewlipski you may want to review this implementation too, to see which is worth keeping: #2592 test case might be good to take from there |
Summary
When adding a link, if the end aligns with the end of a comment, the comment will be removed across the content spanned by the link.
This is because adding a link calls
tr.insertText, which replaces the content spanned by the link. This is a problem especially with comments as they are notinclusivein their TipTap mark spec. Therefore, when content that they cover gets replaced, they get cleared instead of preserved.This PR makes it so that
tr.insertTextonly gets called if the text has actually changed, which doesn't happen in most cases. If it does happen, there are a bunch of edge cases that have to be considered, e.g.:Given the following content, where {} marks the span of a link and [] marks the span of a comment:
If the link's text is changed to something completely different, like "qwe", where should the comment start?
Therefor, this PR only covers the case where the text remains the same.
Closes #2573
Rationale
It's annoying for users to accidentally clear comments when trying to add links.
Changes
tr.insertTextget called conditionally increateLink.Impact
N/A
Testing
TODO
Screenshots/Video
N/A
Checklist
Additional Notes
Summary by CodeRabbit