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
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
* 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 double paste due to insertTextData being called when it should not
* Document return type of insertTextData and insert FragmentData
* Add changeset
* Updates "Saving to a Database" example to distinguish actual content changes.
* Update docs/walkthroughs/06-saving-to-a-database.md
* Update docs/walkthroughs/06-saving-to-a-database.md
* Update docs/walkthroughs/06-saving-to-a-database.md
* Runs prettier
* docs: clarifies not setting editor values directly & plugin order
* Changes reccommended order of withReact & withHistory, to match current knowleged
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
To see the problem, visit https://docs.slatejs.org/general/changelog and follow the links after "...each package will maintain its own individual changelog, which you can find here:"
* Proposal for Remove useCallback from walkthroughs
I have seen in the walkthrough the use of `useCallback` but I don't think are need it, and add a small complexity while understanding the concept, if we moved out the function outside of the component will be stable and will not require to maintain either referential identity or calculated complex logic.
If people think this is a good idea I can go and update all documentation to remove unnecessary `useCallback` from the example.
unless I'm missing something.
* Update docs/walkthroughs/04-applying-custom-formatting.md
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
* Add third parameter to `toSlateRange` method
The `toSlateRange` method accepts an optional third parameter that is an object with property `exactMatch` and value is a boolean.
Example of this implementation can be found at the `Editable` component of `slate-react`, inside the custom `onDOMSelectionChange`.
* toSlateRange third param is optional
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
No changeset as it's a doc update.
