* 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>
* fix: resolve CJK IME double input
* fix: resolve UC mobile no input issue
* feat: add changeset
* Update .changeset/large-melons-warn.md
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
* fix: more specific way to deal with browsers
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
* Adds clarification & examples to demystify Transforms.
* Fleshes out documentation of NodeOptions for Transforms
* Update docs/concepts/04-transforms.md
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
* Uses 'API' in the title of all API documents
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
* Fix `setNodes()` props argument type
Because Typescript can know which type of nodes we are modifying thanks to the `T` inferred from `match` function,
it can also properly narrow down the `props` argument type.
* Fix TS errors in examples
* Add a changeset
It's important to have 100% working examples. Unfortunately this example
I introduced has a bug on Chrome and Safari, where the cursor jumps
around wrongly when using the "up" and "down" keys to navigate. This
is due to a browser bug with display:inline-block elements, and there
is no known workaround except to use display:inline.
* fix double paste due to insertTextData being called when it should not
* Document return type of insertTextData and insert FragmentData
* Add changeset
* make editor.selection avaliable when Editor is contenteditable="false"
* remove dom selection limition of read-only
* Improve grammar of comments regarding selection when read-only is true
* Add Changeset
Co-authored-by: Xheldon <c1006044256@gmail.com>
* Fix crash when a void node deletes itself on click
Fixes https://github.com/ianstormtaylor/slate/issues/4240
* Add 'image delete' feature to example
My immediate motivation is to demonstrate the bug that this fixes. But
this is also a very common editor feature, and I think it's valuable
to show how to achieve it.
* add changeset
* fix:eslint
* revert changes to mentions.tsx
* Official custom inlines example
This generalizes the "links" example to an "inlines" example, adding
a new example of an inline: an "editable button".
Firstly, this is important to demonstrate that Slate really does allow
_custom_ elements, and not just "standard" ones like links that you'll
find in any editor.
Secondly, it's important to show an example of an inline where "offset"
movement should be used. With links, it's arguable that the cursor
positions <link>foo<cursor/></link> and <link>foo</link><cursor/>
should be considered the same, because they display in the same
position. But with the editable button, the cursor is clearly in a
different position, and so offset movement should be used.
* lint
* fix integration test
* update readme
* try again
* Allow typing at the end of an inline
This fixes https://github.com/ianstormtaylor/slate/issues/4524
Steps to reproduce the buggy behavior:
* Create a page with an inline element, or go to
https://codepen.io/jameshfisher/pen/xxrXvVO
* Put the cursor at the end of the inline code element
* Type something
Expected behavior: If the cursor is at the end of an inline, text
should be inserted at the end of the inline.
Actual behavior: Slate moves the cursor outside the inline before
inserting text.
This current behavior is explicitly coded. I nevertheless claim that
this is a bug, or at least a misfeature in core. My expected behavior
comes from:
* The fact that the cursor is inside the inline. For the user, the
blinking cursor is visually inside the inline, not outside it. For the
developer, the cursor (i.e. editor.selection) is inside the inline,
not outside it. The definition of "the cursor" is "this is where your
text will go when you type". To break that behavior is really jarring.
* Slate's principle that "all of its logic is implemented with a series
of plugins". If the current behavior is actually desirable in some
circumstance, it should be in a plugin, not core. It's harder and less
elegant for me to remove the core behavior with my own plugin.
* Comparison with other editors. The following editors all insert text
at the end of the inline, as expected: default contenteditable,
Medium, Coda.io, Google Docs, OneNote, Evernote, QuillJS, TinyMCE,
EditorJS, ProseMirror. Two editors with the current buggy behavior are
Notion and Dropbox Paper, but I find it hard to imagine that their
current behavior on this issue is actually designed, and not just
accidental.
* Usability: how else is the user supposed to enter text at the end of
the inline ..? The only way seems to be to insert text before the end
of the inline, and then delete the rest of the inline. This is
obviously horrible.
* add changeset
* Fix test: insert at the end of an inline should _not_ have special behavior
* The selection is no longer moved in insertText so we don't need this special case
* fix:prettier
* Revert "The selection is no longer moved in insertText so we don't need this special case"
This reverts commit f9f36cd43937ed44272294c1c3c19ca2f3302f2d.
* Explain the real reason for this special case - native browser bugs
Due to standard link CSS, the cursor at the end of the link looks the
same as the cursor immediately after the link, and the cursor at the
start of the link looks the same as the cursor immediately before the
link. However, these are semantically different locations. I've had
several problems with Slate misinterpreting these locations, and had
trouble showing these problems to others using the standard examples,
because the only example of an editable inline element is the link.
To fix this, I've added a box-shadow to the link when it's selected. It
should now be clear to the user whether the cursor is inside or
outside the element.
