#### Is this adding or improving a _feature_ or fixing a _bug_?
Adding and improving
#### What's the new behavior?
Renames the following node methods (deprecating the old ones):
- `getBlocksAtRangeAsArray` -> `getLeafBlocksAtRangeAsArray`
- `getBlocksAtRange` -> `getLeafBlocksAtRange`
- `getInlinesAtRangeAsArray` -> `getLeafInlinesAtRangeAsArray`
- `getInlinesAtRange` -> `getLeafInlinesAtRange`
Adds the following nodes methods:
- `getRootBlocksAtRange`
- `getRootInlinesAtRange`
#### How does this change work?
Have not changed the implementation of the renamed methods. Added tests for both renamed methods and added methods.
#### Have you checked that...?
* [x] The new code matches the existing patterns and styles.
* [x] The tests pass with `yarn test`.
* [x] The linter passes with `yarn lint`. (Fix errors with `yarn prettier`.)
* [x] The relevant examples still work. (Run examples with `yarn watch`.)
#### Does this fix any issues or need any specific reviewers?
Discussed in #2351
* Add possibility to add arbitrary data to operations
Using a data property similar to the node models (block, inline, etc)
* Fix broken example 'Syncing Operations'
Using data property on operations that are applied
* add placeholder plugin in slate-react
* remove renderPlaceholder logic
* extract placeholder into a plugin
* remove other old placeholder-based logic
* update changelogs
* Skip operations on child nodes if !node.nodes.size
Avoid running decoration and text decoration related functions on child nodes that don't exist.
* Uses isLeafBlock
* Restores the original order of statements
#### Is this adding or improving a _feature_ or fixing a _bug_?
Improvement / debt.
#### What's the new behavior?
This pull request removes the `Change` object as we know it, and folds all of its behaviors into the new `Editor` controller instead, simplifying a lot of the confusion around what is a "change vs. editor" and when to use which. It makes the standard API a **lot** nicer to use I think.
---
###### NEW
**The `editor.command` and `editor.query` methods can take functions.** Previously they only accepted a `type` string and would look up the command or query by type. Now, they also accept a custom function. This is helpful for plugin authors, who want to accept a "command option", since it gives users more flexibility to write one-off commands or queries. For example a plugin could be passed either:
```js
Hotkey({
hotkey: 'cmd+b',
command: 'addBoldMark',
})
```
Or a custom command function:
```js
Hotkey({
hotkey: 'cmd+b',
command: editor => editor.addBoldMark().moveToEnd()
})
```
###### BREAKING
**The `Change` object has been removed.** The `Change` object as we know it previously has been removed, and all of its behaviors have been folded into the `Editor` controller. This includes the top-level commands and queries methods, as well as methods like `applyOperation` and `normalize`. _All places that used to receive `change` now receive `editor`, which is API equivalent._
**Changes are now flushed to `onChange` asynchronously.** Previously this was done synchronously, which resulted in some strange race conditions in React environments. Now they will always be flushed asynchronously, just like `setState`.
**The `render*` and `decorate*` middleware signatures have changed!** Previously the `render*` and `decorate*` middleware was passed `(props, next)`. However now, for consistency with the other middleware they are all passed `(props, editor, next)`. This way, all middleware always receive `editor` and `next` as their final two arguments.
**The `normalize*` and `validate*` middleware signatures have changed!** Previously the `normalize*` and `validate*` middleware was passed `(node, next)`. However now, for consistency with the other middleware they are all passed `(node, editor, next)`. This way, all middleware always receive `editor` and `next` as their final two arguments.
**The `editor.event` method has been removed.** Previously this is what you'd use when writing tests to simulate events being fired—which were slightly different to other running other middleware. With the simplification to the editor and to the newly-consistent middleware signatures, you can now use `editor.run` directly to simulate events:
```js
editor.run('onKeyDown', { key: 'Tab', ... })
```
###### DEPRECATED
**The `editor.change` method is deprecated.** With the removal of the `Change` object, there's no need anymore to create the small closures with `editor.change()`. Instead you can directly invoke commands on the editor in series, and all of the changes will be emitted asynchronously on the next tick.
```js
editor
.insertText('word')
.moveFocusForward(10)
.addMark('bold')
```
**The `applyOperations` method is deprecated.** Instead you can loop a set of operations and apply each one using `applyOperation`. This is to reduce the number of methods exposed on the `Editor` to keep it simpler.
**The `change.call` method is deprecated.** Previously this was used to call a one-off function as a change method. Now this behavior is equivalent to calling `editor.command(fn)` instead.
---
Fixes: https://github.com/ianstormtaylor/slate/issues/2334
Fixes: https://github.com/ianstormtaylor/slate/issues/2282
* Add failing deleteAtRange test
* Fix invalid move node path increment (fixes#2291)
* Add another three block delete all test without any void nodes
* Test the correct variables in transform path (move_node)
#### Is this adding or improving a _feature_ or fixing a _bug_?
Fixing a bug. This is a proposed solution for https://github.com/ianstormtaylor/slate/issues/2064 (which also aims to maintain the existing _single nested block_ behavior added in https://github.com/ianstormtaylor/slate/pull/1366).
#### What's the new behavior?
Today, we always insert all nodes of the fragment at the range.
After this change, if the fragment is wrapped by/nested in blocks, and the nesting pattern already exists at the range, we meld the fragment contents into the document’s existing nesting pattern as much as possible.
Put another way, we can skip adding the fragment’s wrapping nodes if equivalent nodes already wrap the range.
Here’s a quick sketch that may better demonstrate the intention:
Here, both the document and fragment wrap their content in two paragraphs. Therefore, we can add the fragment contents within the existing pair of nested paragraphs.
#### How does this change work?
A new function is added, `findInsertionNode`. Given a `fragment`, `document`, and `startKey`, it returns a node from the fragment to be inserted into the document. By default, the node returned will be the `fragment`, but if a common nesting pattern is detected, a sub-node of the fragment will be returned.
The detection algorithm is as follows:
1. Ensure the fragment has a single child node, call it `fragmentInner`
2. Find the furthest document ancestor of the `startKey` matching `fragmentInner.type`. Call this `documentInner`
3. Drill into both `documentInner` and `fragmentInner` as long as each has a single child node and their types match. The stopping point for the fragment is the sub-node to insert into the document.
`Commands.insertFragmentAtRange` remains mostly unchanged. One important modification is that the _single nested block_ (again, see https://github.com/ianstormtaylor/slate/pull/1366) only happens if the found insertion node is the fragment. For anything more inner, we meld.
#### Have you checked that...?
* [x] The new code matches the existing patterns and styles.
* [x] The tests pass with `yarn test`.
* [x] The linter passes with `yarn lint`. (Fix errors with `yarn prettier`.)
* [x] The relevant examples still work. (Run examples with `yarn watch`.)
#### Does this fix any issues or need any specific reviewers?
Fixes: https://github.com/ianstormtaylor/slate/issues/2064
Previously, `start-inline` and `end-inline` included the cursor at the end of an inline, i.e.
```js
<paragraph>
<link>example<cursor /></link>
</paragraph>
```
Using Slate in a browser, it doesn’t seem possible to me to actually achieve this state: i.e. whenever the cursor is on either side of an inline such as a link, typing will not add text to that inline. (This is consistent with other editors, for example Google Docs).
Now, these tests are updated to have a cursor just outside the inline. This leads to more sensible outputs.
(Finally, I removed a TODO comment indicating that `middle-inline-fragment-inline`’s cursor output was incorrect. I believe this is a sensible expectation, which matches behavior in editors including Google Docs.)
Fixes https://github.com/ianstormtaylor/slate/issues/1754
https://github.com/ianstormtaylor/slate/issues/1879
When composition starts and the current selection is not collapsed, the
second composition key-down would drop the text wrapping <spans> which
resulted on crash in content.updateSelection after composition ends
(because it cannot find <span> nodes in DOM). This is a workaround that
erases selection as soon as composition starts and preventing <spans>
to be dropped.
