Changelog History
Page 1
-
v0.58.3
June 04, 2020 -
v0.58.2
May 27, 2020 -
v0.58.1
May 11, 2020 -
v0.58.0 Changes
May 05, 2020BREAKING
👉 User properties on Elements and Texts now have an unknown type instead of any. Previously, the arbitrary user defined keys on the
Text
andElement
interface had a type ofany
which effectively removed any potential type checking on those properties. Now these have a type ofunknown
so that type checking can be done by consumers of the API when they are applying their own custom properties to theText
s andElement
s.
-
v0.57.3
May 05, 2020 -
v0.57.2
April 24, 2020 -
v0.57.1
December 20, 2019 -
v0.57.0 Changes
December 18, 2019BREAKING
Overridable commands now live directly on the editor object. Previously the
Command
concept was implemented as an interface that was passed into theeditor.exec
function, allowing the "core" commands to be overridden in one place. But this introduced a lot of Redux-like indirection when implementing custom commands that wasn't necessary because they are never overridden. Instead, now the core actions that can be overridden are implemented as individual functions on the editor (eg.editor.insertText
) and they can be overridden just like any other function (eg.isVoid
).Previously to override a command you'd do:
const withPlugin = editor => { const { exec } = editor editor.exec = command => { if (command.type === 'insert_text') { const { text } = command if (myCustomLogic) { // ... return } } exec(command) } return editor }
Now, you'd override the specific function directly:
const withPlugin = editor => { const { insertText } = editor editor.insertText = text => { if (myCustomLogic) { // ... return } insertText(text) } return editor }
🔌 You shouldn't ever need to call these functions directly! They are there for plugins to tap into, but there are higher level helpers for you to call whenever you actually need to invoke them. Read on…
Transforms now live in a separate namespace of helpers. Previously the document and selection transformation helpers were available directly on the
Editor
interface asEditor.*
. But these helpers are fairly low level, and not something that you'd use in your own codebase all over the place, usually only inside specific custom helpers of your own. To make room for custom userland commands, these helpers have been moved to a newTransforms
namespace.Previously you'd write:
Editor.unwrapNodes(editor, ...)
Now you'd write:
Transforms.unwrapNodes(editor, ...)
🚚 The
Command
interfaces were removed. As part of those changes, the existingCommand
,CoreCommand
,HistoryCommand
, andReactCommand
interfaces were all removed. You no longer need to define these "command objects", because you can just call the functions directly. Plugins can still define their own overridable commands by extending theEditor
interface with new functions. Theslate-react
plugin does this withinsertData
and theslate-history
plugin does this withundo
andredo
.NEW
👉 User action helpers now live directly on the
Editor.*
interface. These are taking the place of the existingTransforms.*
helpers that were moved. These helpers are equivalent to user actions, and they always operate on the existing selection. There are some defined by core, but you are likely to define your own custom helpers that are specific to your domain as well.For example, here are some of the built-in actions:
Editor.insertText(editor, 'a string of text') Editor.deleteForward(editor) Editor.deleteBackward(editor, { unit: 'word' }) Editor.addMark(editor, 'bold', true) Editor.insertBreak(editor) ...
Every one of the old "core commands" has an equivalent
Editor.*
helper exposed now. However, you can easily define your own custom helpers and place them in a namespace as well:const MyEditor = { ...Editor, insertParagraph(editor) { ... }, toggleBoldMark(editor) { ... }, formatLink(editor, url) { ... }, ... }
Whatever makes sense for your specific use case!
-
v0.56.1
December 18, 2019 -
v0.56.0 Changes
December 17, 2019BREAKING
The
format_text
command is split intoadd_mark
andremove_mark
. Although the goal is to keep the number of commands in core to a minimum, having this as a combined command made it very hard to write logic that wanted to guarantee to only ever add or remove a mark from a text node. Now you can be guaranteed that theadd_mark
command will only ever add custom properties to text nodes, and theremove_mark
command will only ever remove them.Previously you would write:
editor.exec({ type: 'format_text', properties: { bold: true }, })
Now you would write:
if (isActive) { editor.exec({ type: 'remove_mark', key: 'bold' }) } else { editor.exec({ type: 'add_mark', key: 'bold', value: true }) }
🤖 Note that the "mark" term does not mean what it meant in
0.47
and earlier. It simply means formatting that is applied at the text level—bold, italic, etc. We need a term for it because it's such a common pattern in richtext editors, and "mark" is often the term that is used. For example the<mark>
tag in HTML.The
Node.text
helper was renamed toNode.string
. This was simply to reduce the confusion between "the text string" and "text nodes". The helper still just returns the concatenated string content of a node.