Using TypeScript

slate supports typing of one slate document model (ie one set of custom editor , element and text types) if you need to support more than one document model, see the section multiple document models warning you must define customtypes , annotate usestate , and annotate the editor's initial state when using typescript or slate will display typing errors migrating from 0 47 x when migrating from 0 47 x, read the guide below first also keep in mind these common migration issues when referring to node type , you may see the error property 'type' does not exist on type 'node' to fix this, you need to add code like element iselement(node) && node type === 'paragraph' this is necessary because a node can be an element or text and text does not have a type property be careful when you define the customtype for editor make sure to define the customtype for editor as baseeditor & it should not be editor & defining editor , element and text types to define a custom element or text type, extend the customtypes interface in the slate module like this // this example is for an editor with `reacteditor` and `historyeditor` import { baseeditor } from 'slate' import { reacteditor } from 'slate react' import { historyeditor } from 'slate history' type customelement = { type 'paragraph'; children customtext\[] } type customtext = { text string; bold? true } declare module 'slate' { interface customtypes { editor baseeditor & reacteditor & historyeditor element customelement text customtext } } annotations in the editor annotate the editor's initial value w/ descendant\[] import react, { usememo, usestate } from 'react' import { createeditor, descendant } from 'slate' import { slate, editable, withreact } from 'slate react' const initialvalue descendant\[] = \[ { type 'paragraph', children \[{ text 'a line of text in a paragraph ' }], }, ] const app = () => { const editor = usememo(() => withreact(createeditor()), \[]) return ( \<slate editor={editor} value={initialvalue}> \<editable /> \</slate> ) } best practices for element and text types while you can define types directly in the customtypes interface, best practice is to define and export each type separately so that you can reference individual types like a paragraphelement using best practices, the custom types might look something like // this example is for an editor with `reacteditor` and `historyeditor` import { baseeditor } from 'slate' import { reacteditor } from 'slate react' import { historyeditor } from 'slate history' export type customeditor = baseeditor & reacteditor & historyeditor export type paragraphelement = { type 'paragraph' children customtext\[] } export type headingelement = { type 'heading' level number children customtext\[] } export type customelement = paragraphelement | headingelement export type formattedtext = { text string; bold? true } export type customtext = formattedtext declare module 'slate' { interface customtypes { editor customeditor element customelement text customtext } } in this example, customtext is equal to formattedtext but in a real editor, there can be more types of text like text in a code block which may not allow formatting for example why is the type definition unusual because it gets asked often, this section explains why slate's type definition is atypical slate needs to support a feature called type discrimination which is available when using union types (e g paragraphelement | headingelement ) this allows a user to narrow a type if presented with code like if (node type === 'paragraph') { } the inside of the block, will narrow the type of node to paragraphelement slate also needs a way to allow developers to get their custom types into slate this is done through declaration merging which is a feature of an interface slate combines a union type and an interface in order to use both features for more information see proposal add custom typescript types to slate https //github com/ianstormtaylor/slate/issues/3725 multiple document models at the moment, slate supports types for a single document model at a time for example, it cannot support two different rich text editor with different document schemas slate's typescript support was designed this way because typing for one document schema was better than none the goal is to eventually support typing for multiple editor definitions and there is currently an in progress pr built by the creator of slate one workaround for supporting multiple document models is to create each editor in a separate package and then import them this hasn't been tested but should work extending other types currently there is also support for extending other types but these haven't been tested as thoroughly as the ones documented above selection range point feel free to extend these types but extending these types should be considered experimental please report bugs on github issues typescript examples for some examples of how to use types, see packages/slate react/src/custom types ts in the slate repository