#### 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_?
Debt.
#### What's the new behavior?
This removes almost all existing deprecations from previous API changes, to save on filesize and reduce complexity in the codebase going forward.
It also changes from using the `slate-dev-logger` to using the Facebook-inspired `slate-dev-warning` which can be compiled out of production builds with [`babel-plugin-dev-expression`](https://github.com/4Catalyzer/babel-plugin-dev-expression) to save even further on file size.
The only deprecations it keeps are in the `fromJSON` methods for data model changes like `.kind` and `.leaves` which may still may not have been migrated in databases, since this is a bigger pain point.
#### 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: #1922Fixes: #2105Fixes: #646Fixes: #2109Fixes: #2107Fixes: #2018
#### 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
#### 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
* fixed build for windows
* fixed issue where undo of merge node does not restore the node back to its original properties
* fixed lint issue
* updated operation docs for additional property on split_node and merge_node
* finished incomplete sentence in the docs.
* updated test to also verify data is restored
* renamed the 'original' property to 'properties' to be more consistent with similar operation interfaces, updated docs
* got rid of extra operations property.
* deserializing properties in merge_node and split_node, passing properties object in splitNodeByKey
* missed committing operations modles.
* updated operations.toJSON for new properties on merge_node and split_node
* fix linting error
* remove outdated comment.
* expanded check for split node inverse to include inline nodes
* partially revert update to test with deletion across inlines
* change normalization can be set with setOperationFlag, and changes can be executed in sequence with automatic suppression with guaranteed document normalization at the end.
* responded to developer feedback by renaming execute to withMutations (to mirror immutable JS), implemented tests, updated documentation
* fixed typos discovered in review.
* fixed missing normalize flag usages and added withMutations to the schemas guide
* responded to developer feedback
* fixed lint errors and cleaned up code
* readd missing tests
* getFlag now allows options to override the change flags
* removed normalize restoration asserts from unit tests
* unit test cleanup
* added export constant enum for schema violations
* updated examples to use the schema violations enum
* use SchemaViolations enum in tests and docs
* fixed path for schema violations import
* 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
