fix(slate-dom): propagate suppressThrow to toSlateNode in toSlatePoint#6072
Open
pangoyal-gong wants to merge 3 commits into
Open
Conversation
…ePoint When toSlatePoint is called with suppressThrow: true, errors thrown by toSlateNode were not being suppressed — only errors from findPath were handled. Wrap the toSlateNode call in the same try/catch pattern already used for findPath. This is the gap left by PR ianstormtaylor#6004 which guarded findPath but not the preceding toSlateNode call.
🦋 Changeset detectedLatest commit: 5a47415 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
dylans
approved these changes
Jun 24, 2026
dylans
requested changes
Jun 24, 2026
dylans
left a comment
Collaborator
There was a problem hiding this comment.
@pangoyal-gong needs a quick prettier run please on the changeset, likely needs a single-quote change and a shorter line.
dylans
approved these changes
Jun 30, 2026
dylans
requested changes
Jun 30, 2026
dylans
left a comment
Collaborator
There was a problem hiding this comment.
Forgot this still needs prettier changes to land it please.
NikunjSonigara
added a commit
to NikunjSonigara/slate
that referenced
this pull request
Jul 1, 2026
…Throw Address review feedback on ianstormtaylor#6073: instead of silently swallowing the error, add an opt-in `suppressThrow` option to `useSelected` so the hook keeps throwing by default and callers opt in to returning `false` when the element can no longer be resolved. Follows the `suppressThrow` pattern from ianstormtaylor#6072. Also trim the explanatory comments.
Author
|
@dylans pushed. |
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.
Problem
toSlatePointaccepts asuppressThrowoption that is supposed to prevent it from throwing when a DOM node cannot be resolved to a Slate point. However, the implementation only suppresses errors fromfindPath— errors thrown bytoSlateNode(called on the line immediately before) are not guarded.This means that callers passing
suppressThrow: truecan still receive an unhandledError: Cannot resolve a Slate node from DOM nodeexception thrown bytoSlateNode, defeating the purpose of the option.Affected code path
In
packages/slate-dom/src/plugin/dom-editor.ts, thetoSlatePointimplementation:A common trigger: the document-level
selectionchangelistener inslate-reactcallstoSlatePointwithsuppressThrow: true, but receives the error anyway becausetoSlateNodeis not guarded. This produces high-volume Sentry noise for applications using Slate in a React portal or with multiple editors on the page.Relationship to PR #6004
PR #6004 added
suppressThrowhandling tofindPathinsidetoSlatePoint. This fix applies the same pattern one step earlier, to thetoSlateNodecall that precedes it.Fix
Wrap the
toSlateNodecall in the sametry/catchpattern already used forfindPath:Testing
The change is minimal and mirrors the existing pattern in the same function. The behavior when
suppressThrowisfalse(or omitted) is unchanged — errors still propagate as before.