* use focusin and focusout without capture if react >= 17
See https://github.com/facebook/react/pull/19186 for details on changes to `onFocus` and `onBlur`
* more accurate name for react version check const
* add changeset
* add comment about react >= 17 focus event listeners
* Fix NODE_TO_KEY correction for split_node and merge_node
* fix lint
* add changeset
* Add NODE_TO_KEY tests for number of mounts for split_node and merge_node
* feat: add merge to setNodes
* chore: add merge to setNodes test
* chore: prettier
* chore: change to PropsMerge
* chore: restore the changes for addMark
If you have a nested editor setup. For example, one editor has a void node that contains another editor. In this case, a resolution of a selection by the nested editor previously would consider that the selection is for a void node since an ancestor void node does exist. However, this selection is only a void node in the context of this editor if the ancestor void node is contained in the editor.
* test changes
* fix decoration not updating
* Add changeset
* Fix lint issues
* Tests with earlier version of Node.js
* Bump node version on CI
The base typescript config uses ESNext as target, so presumably the
latest node should be used.
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
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
