Nodes

the most important types are the node objects a root level editor node that contains the entire document's content container element nodes which have semantic meaning in your domain and leaf level text nodes which contain the document's text these three interfaces are combined together to form a tree—just like the dom for example, here's a simple plaintext value const editor = { children \[ { type 'paragraph', children \[ { text 'a line of text!', }, ], }, ], // the editor has other properties too } mirroring the dom as much as possible is one of slate's principles people use the dom to represent documents with richtext like structures all the time mirroring the dom helps make the library familiar for new users, and it lets us reuse battle tested patterns without having to reinvent them ourselves 🤖 the following content on mozilla's developer network may help you learn more about the corresponding dom concepts https //developer mozilla org/en us/docs/web/api/document https //developer mozilla org/en us/docs/web/html/block level elements https //developer mozilla org/en us/docs/web/html/inline elements https //developer mozilla org/en us/docs/web/api/text a slate document is a nested and recursive structure in a document, elements can have children nodes—all of which may have children nodes without limit the nested and recursive structure enables you to model simple behaviors such as user mentions and hashtags or complex behaviors such as tables and figures with captions editor the top level node in a slate document is the editor itself it encapsulates all of the richtext "content" of the document its interface is interface editor { children node\[] } we'll cover its functionality later, but the important part as far as nodes are concerned is its children property which contains a tree of node objects element elements make up the middle layers of a richtext document they are the nodes that are custom to your own domain their interface is interface element { children node\[] } you can define custom elements for any type of content you want for example you might have paragraphs and quotes in your data model which are differentiated by a type property const paragraph = { type 'paragraph', children \[ ], } const quote = { type 'quote', children \[ ], } it's important to note that you can use any custom properties you want the type property in that example isn't something slate knows or cares about if you were defining your own "link" nodes, you might have a url property const link = { type 'link', url 'https //example com', children \[ ], } or maybe you want to give all of your nodes id an property const paragraph = { id 1, type 'paragraph', children \[ ], } all that matters is that elements always have a children property blocks vs inlines depending on your use case, you might want to define another behavior for element nodes which determines their editing "flow" all elements default to being "block" elements they each appear separated by vertical space, and they never run into each other but in certain cases, like for links, you might want to make them "inline" flowing elements instead that way they live at the same level as text nodes, and flow 🤖 this is a concept borrowed from the dom's behavior, see https //developer mozilla org/en us/docs/web/html/block level elements and https //developer mozilla org/en us/docs/web/html/inline elements you can define which nodes are treated as inline nodes by overriding the editor isinline function (by default it always returns false ) note that inline nodes cannot be the first or last child of a parent block, nor can it be next to another inline node in the children array slate will automatically space these with { text '' } children by default with normalizing docid\ kuztmwra9iuot07 sj5rm elements can either contain block elements or inline elements intermingled with text nodes as children but elements cannot contain some children that are blocks and some that are inlines voids similar to blocks and inlines, there is another element specific behavior you can define depending on your use case their "void" ness elements default to being non void, meaning that their children are fully editable as text but in some cases, like for images, you want to ensure that slate doesn't treat their content as editable text, but instead as a black box 🤖 this is a concept borrowed from the html spec, see https //www w3 org/tr/2011/wd html markup 20110405/syntax html#void element you can define which elements are treated as void by overriding the editor isvoid function (by default it always returns false ) text text nodes are the lowest level nodes in the tree, containing the text content of the document, along with any formatting their interface is interface text { text string } for example, a string of bold text const text = { text 'a string of bold text', bold true, } text nodes too can contain any custom properties you want, and that's how you implement custom formatting like bold , italic , code , etc