0.50.xversions is not a simple task. The entire framework was re-considered from the ground up. This has resulted in a much better set of abstractions, which will result in you writing less code. But the migration process is not simple.
0.50.xversion of Slate from an architectural point of view.
node.datacan now live at the top-level of the nodes.
Range.isCollapsed(range). This ends up making code much clearer because you can always quickly see what interface you're working with.
Decorationused to all be separate classes. Now they are simply objects that implement the
Inlinewere separate; now they are objects that implement the
Elementinterface. Previously there was a
Value, but now the top-level
Editorcontains the children nodes of the document itself.
insertTextAtPath. These have been merged into a smaller set of more customizable commands, eg.
insertTextwhich can take
at: Path | Range | Point.
slate-base64-serializer, etc. have been removed and can be implemented in userland easily if needed. Even the
slate-html-deserializercan now be implemented in userland (in ~10 LOC leveraging
slate-hyperscript). And internal packages like
slate-dev-test-utils, etc. are no longer exposed because they are implementation details.
keydownevents you should likely override command behaviors instead.
editor.*core functions. And they travel through a middleware-like stack, but built from composed functions. Any plugin can override the behaviors to augment an editor.
Editorobject they receive and return it again. For example, they can augment the command execution by composing the
editor.execfunction or listen to operations by composing
editor.apply. Previously they relied on a custom middleware stack, and they were just bags of handlers that got merged onto an editor. Now we're using plain old function composition (aka wrapping) instead.
object: 'inline'attributes. Now, it checks whether an "element" is inline or not at runtime. For example, you might check to see that
element.type === 'link'and treat it as inline.
<Editor>component was doing double duty as a sort of "controller" object and also the
contenteditableDOM element. This led to a lot of awkwardness in how other components worked with Slate. In the new version, there is a new
<Slate>context provider and a simpler
contenteditable-like component. By putting the
<Slate>provider higher up in your component tree, you can share the editor directly with toolbars, buttons, etc. using the
useSlatehook, there are a handful of other hooks. For example the
useFocusedhooks help with knowing when to render selected states (often for void nodes). And since they use React's Context API they will automatically re-render when their state changes.
beforeinputevent almost exclusively. Instead of relying on a series of shims and the quirks of React synthetic events, we're now using the standardized
beforeinputevent as our baseline. It is fully supported in Safari and Chrome, will soon be supported in the new Chromium-based Edge, and is currently being worked on in Firefox. In the meantime there are a few patches to make Firefox work. Internet Explorer is no longer supported in core out of the box.