8dd919dc34
#### 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
2.8 KiB
Previous:
Installing Slate
Adding Event Handlers
Okay, so you've got Slate installed and rendered on the page, and when you type in it, you can see the changes reflected. But you want to do more than just type a plaintext string.
What makes Slate great is how easy it is to customize. Just like other React components you're used to, Slate allows you to pass in handlers that are triggered on certain events. You've already seen how the onChange handler can be used to store the changed editor value, but let's try adding more...
Let's use the onKeyDown handler to change the editor's content when we press a key.
Here's our app from earlier:
class App extends React.Component {
state = {
value: initialValue,
}
onChange = ({ value }) => {
this.setState({ value })
}
render() {
return <Editor value={this.state.value} onChange={this.onChange} />
}
}
Now we add an onKeyDown handler:
class App extends React.Component {
state = {
value: initialValue,
}
onChange = ({ value }) => {
this.setState({ value })
}
// Define a new handler which prints the key that was pressed.
onKeyDown = (event, editor, next) => {
console.log(event.key)
return next()
}
render() {
return (
<Editor
value={this.state.value}
onChange={this.onChange}
onKeyDown={this.onKeyDown}
/>
)
}
}
Cool, now when a key is pressed in the editor, its corresponding keycode is logged in the console.
Now we want to make it actually change the content. For the purposes of our example, let's implement turning all ampersand, &, keystrokes into the word and upon being typed.
Our onKeyDown handler might look like this:
class App extends React.Component {
state = {
value: initialValue,
}
onChange = ({ value }) => {
this.setState({ value })
}
onKeyDown = (event, editor, next) => {
// Return with no changes if the keypress is not '&'
if (event.key !== '&') return next()
// Prevent the ampersand character from being inserted.
event.preventDefault()
// Change the value by inserting 'and' at the cursor's position.
editor.insertText('and')
return true
}
render() {
return (
<Editor
value={this.state.value}
onChange={this.onChange}
onKeyDown={this.onKeyDown}
/>
)
}
}
With that added, try typing &, and you should see it suddenly become and instead!
This offers a sense of what can be done with Slate's event handlers. Each one will be called with the event object, and the editor that lets you perform commands. Simple!
Next:
Defining Custom Block Nodes