#### 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
* fold Stack into Editor
* switch Change objects to be tied to editors, not values
* introduce controller
* add the "commands" concept
* convert history into commands on `value.data`
* add the ability to not normalize on editor creation/setting
* convert schema to a mutable constructor
* add editor.command method
* convert plugin handlers to receive `next`
* switch commands to use the onCommand middleware
* add queries support, convert schema to queries
* split out browser plugin
* remove noop util
* fixes
* fixes
* start fixing tests, refactor hyperscript to be more literal
* fix slate-html-serializer tests
* fix schema tests with hyperscript
* fix text model tests with hyperscript
* fix more tests
* get all tests passing
* fix lint
* undo decorations example update
* update examples
* small changes to the api to make it nicer
* update docs
* update commands/queries plugin logic
* change normalizeNode and validateNode to be middleware
* fix decoration removal
* rename commands tests
* add useful errors to existing APIs
* update changelogs
* cleanup
* fixes
* update docs
* add editor docs
#### Is this adding or improving a _feature_ or fixing a _bug_?
Improvement.
#### What's the new behavior?
This changes the normalization logic to be operations (and `key`) based, instead of the current logic which is more haphazard, and which has bugs that lead to non-normalized documents in certain cases.
#### How does this change work?
Now, every time a change method is called, after it applies its operations, those operations will be normalized. Based on each operation we can know exactly which nodes are "dirty" and need to be re-validated.
This change also makes it easy for the `withoutNormalizing` (previously `withoutNormalization`) helper to be much more performant, and only normalize the "dirty" nodes instead of being forced to handle the entire document.
To accommodate this new behavior, the old "operation flags" have been removed, replaced with a set of more consistent helpers:
- `withoutNormalizing`
- `withoutSaving`
- `withoutMerging`
All of them take functions that will be run with the desired behavior in scope, similar to how Immutable.js's own `withMutations` works. Previously this was done with a more complex set of flags, which could be set and unset in a confusing number of different ways, and it was generally not very well thought out. Hopefully this cleans it up, and makes it more approachable for people.
We also automatically use the `withoutNormalizing` helper function for all of the changes that occur as part of schema `normalize` functions. Previously people had to use `{ normalize: false }` everywhere in those functions which was error-prone.
With this new architecture, you sure almost never need to think about normalization. Except for cases where you explicitly want to move through an interim state that is invalid according to Slate's default schema or your own custom schema. In which case you'd use `withoutNormalizing` to allow the invalid interim state to be moved through.
#### 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: #1363Fixes: #2134Fixes: #2135Fixes: #2136Fixes: #1579Fixes: #2132Fixes: #1657
#### Is this adding or improving a _feature_ or fixing a _bug_?
Improvement.
#### What's the new behavior?
This introduces two new models: `Decoration` and `Selection`, which both implement the simpler `Range` interface. This way we can introduce properties to these concepts without having to have them live on all ranges, and we can start to introduce more helpful methods specific to each one's needs.
It also means we don't need to move `isFocused` to value, which saves some complexity on the operations side, retaining `set_selection` as the only way selections are modified.
In the process, it also cleans up a lot of the existing model logic for implementing the `Node` interface, and introduces another `Common` interface for shared properties of all Slate models.
#### How does this change work?
It introduces a new `interfaces/` directory where common sets of properties can be declared, and mixed in to the models with the new (simple) `mixin` utility.
#### 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: #1952Fixes: #1807
Fixes: https://github.com/ianstormtaylor/slate/issues/2110
#### Is this adding or improving a _feature_ or fixing a _bug_?
Feature.
#### What's the new behavior?
This pull request adds paths to `Range` objects, including the selection. The paths and keys are kept in sync automatically, so that you can use whichever is ideal for your use case.
This should allow us to use paths for lots of the internal logic, which are much quicker to work with than keys since they avoid having to lookup the key in the document and can just traverse right to the node in question.
#### How does this change work?
`Range` objects have two new properties:
```js
range.anchorPath
range.focusPath
```
(Eventually these will be `range.anchor.path` and `range.focus.path` when points are introduced.)
When operations occur and whenever ranges are created/normalized, the paths are updated and kept in sync with the keys.
#### Have you checked that...?
<!--
Please run through this checklist for your pull request:
-->
* [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/1408
Fixes: https://github.com/ianstormtaylor/slate/issues/1567
* initial simple decorations (mark-like), many tests added
* allow decorators to be set by focus, anchor tags - add tests
* handle one more edge case with decorations in hyperscript
* apply prettier cleanup
* apply linting rules
* update changelog
* ensure always normalize decoration ranges
* reapply prettier after latest adjustments
* all operations apply now update decorations with selection
* ranges can now be 'atomic', will invalidate if contents change
* lint, prettier cleanups
* add atomic invalidation tests, update hyperscript usage
* fix linter errors
* minor cleanup
* slight refactor for simplicity
* remove a couple superfluous lines
* update in response to review
* drop unnecessarily committed add'l file
* remove the need for explicit anchor, focus prop on decoration tags
* update hyperscript use to match latest syntax in #1777
* atomic -> isAtomic
* Fix spell check bug by add data-text:true
* Fix spell check bug by spell check add length to a leaf
* Fix tests to use data-text:true for marks
* Rename data-text to data-slate-leaf; Remove setRef; unlift attributes in leaf
* Update examples with data-*
* Add attributes to document
* Fix renderMark in all documents
* Prettier markdown
* Add Prettier, with basic config and ESLint integration
* Apply Prettier to all files using `yarn lint --fix`
* Tell Prettier to ignore an empty text in a test output.
* Run Prettier on JS files not handled by ESLint, and lint them too
* rename state to value in slate core, as deprecation
* rename all references to state to value in slate core
* migrate slate-base64-serializer
* migrate slate-html-serializer
* migrate slate-hyperscript
* migrate slate-plain-serializer
* migrate slate-prop-types
* migrate slate-simulator
* fix change.setState compat
* deprecate references to state in slate-react
* remove all references to state in slate-react
* remove `value` and `schema` from props to all components
* fix default renderPlaceholder
* fix tests
* update examples
* update walkthroughs
* update guides
* update reference
* remove data from event handler signatures
* standardize known transfer types
* add setEventTransfer to docs
* update examples, fix drag/drop
* fix tests and draggable attribute setting
