#### Is this adding or improving a _feature_ or fixing a _bug_?
Improvement.
#### What's the new behavior?
Adds a `Node.createRange` method for more easily creating ranges that are normalized to the current document. As well as a `Node.resolveRange` lower-level method for just doing the normalization on an existing range.
Later we can deprecate `Range.normalize` since it should be on the node instead.
#### 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: #2011
#### Is this adding or improving a _feature_ or fixing a _bug_?
Bug.
#### What's the new behavior?
Fixes selection operations from being duplicated.
#### How does this change work?
Previously the selection properties were compared by reference, but paths are immutable `List` objects, which always show up as having changed, resulting in extra selection operations that without any real changes. We now use `Immutable.is` to remove those duplicates, fixing the undo history stack.
#### 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: #2006
#### Is this adding or improving a _feature_ or fixing a _bug_?
Bug.
#### What's the new behavior?
Fixes `Node.getFragmentAtRange` to use the proper argument signature when calling `Node.splitNode`, and refactors it to use paths for all of its logic.
#### 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: #2009
#### Is this adding or improving a _feature_ or fixing a _bug_?
Improvement.
#### What's the new behavior?
- Tweaking the declarative schema definition syntax to make it easier to represent more complex states, as well as enable it to validate previously impossible things.
- Rename `validateNode` to `normalizeNode` for clarity.
- Introduce `validateNode`, `checkNode`, `assertNode` helpers for more advanced use cases, like front-end API validation of "invalid" fields that need to be fixed before they are sent to the server.
#### How does this change work?
The `schema.blocks/inlines/document` entries are now a shorthand for a more powerful `schema.rules` syntax. For example, this now allows for declaratively validating by a node's data, regardless of type:
```js
{
rules: [
{
match: {
data: { id: '2kd293lry' },
},
nodes: [
{ match: { type: 'paragraph' }},
{ match: { type: 'image' }},
]
}
]
}
```
Previously you'd have to use `validateNode` for this, since the syntax wasn't flexible enough to validate nodes without hard-coding their `type`.
This also simplifies the "concatenation" of schema rules, because under the covers all of them are implemented using the `schema.rules` array, so they simply take effect in order, just like everything else in plugins.
#### 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: #1842Fixes: #1923
* Accept ranges additionally to leaves
For compatibility with older slate JSON documents, additionally to
the new "leaves" property, also accept "ranges" with a deprecation
warning.
* Fix accepting JSON arrays for "ranges" compatibility
#### 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
When inserting a block, we shouldn't split void inlines -- otherwise,
they're duplicated. Instead, move the insert to either before or after
the void node.
* allow fromJSON to restore history
* allow History.toJSON to be passed operations in Arrays instead of Lists
(for example when they have been serialized and deserialized)
* tweak if condition to not make a new List from a List, waste of perf
* s/createList/createOperationsList/ in history.js
* Use slate rather than relative path
* Move benchmark to one dir
* Use slate-* instead of relative path
* Before and After Function
* Remove un-necessary cross-env
* Hard fix
* Lint the hard fix
* Reset memory in bench()
* Working on Benchmark Frameworks
* Rename to slate-dev-benchmark
* Add packages
* Fix prettier bug
* Benchmark framework is in working
* Do not log in test
* max times test
* mute logger in test
* add hr time
* Better support for maxTime; add support of split runs to save memory space
* Fix maxTries
* Add global.gc
* Global gc for each bench
* Better test interface
* Test max-time
* Test max-time done
* Add Benchmark among packages
* Starting to get benchmark running
* Pure Node lib
* Change babelrc for pure Node benchmark
* Moving Benchmarks
* Get benchmark and test running
* Get benchmark for slate-html-serializer
* add slate-react
* add slate/changes
* all benchmarks are converted
* Run benchmark by yarn
* Run benchmark with expose-gc
* Annotate Bench.js
* Do not bundle slate-dev-benchmark in rollup
* Add annotation
* Allow config file to enable part benchmark compare
* Add config for compare
* support compare.js
* Do not re-allocate memory; due to a large heap taken influence result
* Render with Decorations
* get active marks at range
* Fix bug in showing percents
* Fix percent showing bug
* chore: add more benches
* Better output of benchmark
* Fix linting
* decoration and normal as different benchmark test
* Fix deserialize benchmark
* README.md
* Fix Readme.md
* README.md
* block-spacing config
* safer user config loading
* use package.json to load package in test
* Consistent linting
* move components to parent directory
* Annotation styling in package
* margin line before multi-line block
* Fix naive bug
* Fix naive bug
* Fix a blank line
* only log user and hr
* Better name
* Better annotation for runBundleTasks
* Fix typo
* Better logger
* Move async to test
* Omit skip
* Only log the user space time
* Single line async sleep
* file name fix
* Fix annotation
* Better output of compare
* Remove get-characters(-at-range) benchmarks
* Restore emoji
* Capitalize types
* Remove compare to another area
* Add grep and config interface
* Linting files
* Linting benchmarks
* Linting benchmarks
* Update yarn.lock
* Initial fixes for IE compat of cloneFragment
* Used prettier to fix styling
* Removed solutions that can be polyfilled; added COMPAT comment
* Updated FAQ to reflect ideology towards IE
* Update faq.md
* Update faq.md
* Update faq.md
* Added failing test for #1463
* wip
* test passing
* cleaned up, more tests
* lint
* inside inlines working with marks
* lint
* working with leaves
* tidy
* lint issues
* lint - spacing
* using splitText
Right clicks aren't handled by onClick in a content-editable component. So we need access to a onContextMenu handler to handle these events properly.
My use case is to be able to open a context menu with actions when the user right-clicks a specific inline node.
There were three problems preventing drag-and-drop in IE:
* IE [doesn't consider contentEditables as inputs](https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/913982/) when it comes to calling `onDrop`.
* Setting `dropEffect` causes an `unspecified error`.
* You can only get a cursor position from a point with `createTextRange` and `moveToPoint`. Also, `moveToPoint` raises an error if it's called during a dropEvent.
