There is currently no definition of this in the docs, so it's very hard
to understand what this function is supposed to do, and whether it's
buggy. I've written this definition based on Ian Taylor's messages on
Slack [1]:
Jason: Why does unhangRange only unhang the end of a range and not
the start as well? Trying to tell if this is a bug or some logic I'm
not following. If the start of the range is at the last index of a
text shouldn't unhangRange advance that to the next node?
ianstormtaylor: I don’t believe it’s a bug. It was designed to
handle ranges that result from triple-clicks. Not that there might
not be improvements, or that there might not be some other better
way to solve for triple-clicks, or that there might be a better
name for it
Jason: When you say triple-click handling you mean the fact that
the browser selection by default gets placed from start of line to
start of next line? In that cause yes the end of the selection is
where the problem is. If looked at as a more generic implementation
it seems like unhanging the start in cases where you have
{text: 'foo|'}, {text: 'bar|', bold: true} and it makes sense to
normalize the selection to {text: 'foo'},
{text: '|bar|', bold: true} which helps in some cases by avoiding
splits that immediately get merged back, etc.
ianstormtaylor: Yup, that’s exactly right. It was created for the
triple-click case. I agree that something to handle the
start-edged cases would be nice too. But folks in GitHub
discussions have been kind of assuming that the code meant to be
written for both, and that it’s a bug to fix, which isn’t true.
I’m not sure if there are gotchas to expanding the scope to
handle both edges
[1]: https://slate-js.slack.com/archives/CC58ZGGU9/p1632188507024300
* update insertText logic when selection is not collapsed
* add changeset
* fix bug when end of range is void
Co-authored-by: zhangpengcheng15 <zhangpengcheng15@jd.com>
* * remove scheduling of text updates using setTimeout
* call Transforms.setSelection before Editor.insertText
* changeset
* Restore logic to set isComposing to false
As already discussed almost a year ago in #3198, `useMemo` doesn't guarantee persistence. This breaks Fast Refresh.
`useState` without a setter is a straightforward fix that avoids dependencies; let's get the docs updated so Fast Refresh works again.
Fixes#3198
There is a Chromium bug where, if you have an inline at the end of a block,
clicking the end of a block puts the cursor inside the inline
instead of inside the final {text: ''} node.
This commit updates the inlines example to show the problem, and to show
a known workaround for the problem.
See for context: https://github.com/ianstormtaylor/slate/issues/4704
* Warn when normalization removes node
Slate requires the invariant that children are all blocks or all inlines.
It enforces this in default normalization by removing children.
When such a node is removed, it's almost certainly due to a programming
error: the developer needs to fix their application to ensure it
maintains this invariant. But currently Slate does not tell the
developer this.
I made such a programming error, and spent a long time debugging nodes
that mysteriously went missing. I would have fixed it within 30 seconds
if Slate had warned me when it detected this error.
(Note I have used console.warn despite the eslint rule. As far as I can
see, Slate has no other facility for runtime warnings.)
* Add changeset
* Version Packages
* Update CHANGELOG.md
Add a missing changeset from one of the PRs.
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
* slate-react: use a layout effect to render leaf text nodes instead of via virtual DOM, which implements diffing with real DOM avoiding interference with native TextNode behaviors for example spellcheck
* lint
* clarify and simplify extreme case of null text in TextString rendering
* code style: use string interpolation in TextString
Co-authored-by: Nemanja Tosic <netosic90@gmail.com>
Co-authored-by: Peter Sipos <schipy@craft.do>
Co-authored-by: Nemanja Tosic <netosic90@gmail.com>
* fix: isBlockActive should use Array.from()
The richtext.tsx example `isBlockActive` was not working for me in my environtment because `Editor.nodes` returns a Generator, not an Array. So `isBlockActive` always returned false. Wrapping it in `Array.from` fixes the example.
* run prettier
Co-authored-by: Dan Tello <dtello@medallia.com>
