Normalizing

slate editors can edit complex, nested data structures and for the most part this is great but in certain cases inconsistencies in the data structure can be introduced—most often when allowing a user to paste arbitrary richtext content "normalizing" is how you can ensure that your editor's content is always of a certain shape it's similar to "validating", except instead of just determining whether the content is valid or invalid, its job is to fix the content to make it valid again built in constraints slate editors come with a few built in constraints out of the box these constraints are there to make working with content much more predictable than standard contenteditable all of the built in logic in slate depends on these constraints, so unfortunately you cannot omit them they are all element nodes must contain at least one text descendant — even void elements docid\ ko nspe9s4u3zgumayhfo if an element node does not contain any children, an empty text node will be added as its only child this constraint exists to ensure that the selection's anchor and focus points (which rely on referencing text nodes) can always be placed inside any node with this, empty elements (or void elements) wouldn't be selectable two adjacent texts with the same custom properties will be merged if two adjacent text nodes have the same formatting, they're merged into a single text node with a combined text string of the two this exists to prevent the text nodes from only ever expanding in count in the document, since both adding and removing formatting results in splitting text nodes block nodes can only contain other blocks, or inline and text nodes for example, a paragraph block cannot have another paragraph block element and a link inline element as children at the same time the type of children allowed is determined by the first child, and any other non conforming children are removed this ensures that common richtext behaviors like "splitting a block in two" function consistently 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 if this is the case, an empty text node will be added to correct this to be in compliance with the constraint the top level editor node can only contain block nodes if any of the top level children are inline or text nodes they will be removed this ensures that there are always block nodes in the editor so that behaviors like "splitting a block in two" work as expected nodes must be json serializable for example, avoid using undefined in your data model this ensures that operations docid adtwvqlyqajeshk05yaw are also json serializable, a property which is assumed by collaboration libraries property values must not be null instead, you should use an optional property, e g foo? string instead of foo string | null this limitation is due to null being used in operations docid adtwvqlyqajeshk05yaw to represent the absence of a property these default constraints are all mandated because they make working with slate documents much more predictable 🤖 although these constraints are the best we've come up with now, we're always looking for ways to have slate's built in constraints be less constraining if possible—as long as it keeps standard behaviors easy to reason about if you come up with a way to reduce or remove a built in constraint with a different approach, we're all ears! adding constraints the built in constraints are fairly generic but you can also add your own constraints on top of the built in ones that are specific to your domain to do this, you extend the normalizenode function on the editor the normalizenode function gets called every time an operation is applied that inserts or updates a node (or its descendants), giving you the opportunity to ensure that the changes didn't leave it in an invalid state, and correcting the node if so for example here's a plugin that ensures paragraph blocks only have text or inline elements as children import { transforms, element, node } from 'slate' const withparagraphs = editor => { const { normalizenode } = editor editor normalizenode = entry => { const \[node, path] = entry // if the element is a paragraph, ensure its children are valid if (element iselement(node) && node type === 'paragraph') { for (const \[child, childpath] of node children(editor, path)) { if (element iselement(child) && !editor isinline(child)) { transforms unwrapnodes(editor, { at childpath }) return } } } // fall back to the original `normalizenode` to enforce other constraints normalizenode(entry) } return editor } this example is fairly simple whenever normalizenode gets called on a paragraph element, it loops through each of its children ensuring that none of them are block elements and if one is a block element, it gets unwrapped, so that the block is removed and its children take its place the node is "fixed" but what if the child has nested blocks? multi pass normalizing one thing to understand about normalizenode constraints is that they are multi pass if you check the example above again, you'll notice the return statement if (element iselement(child) && !editor isinline(child)) { transforms unwrapnodes(editor, { at childpath }) return } you might at first think this is odd, because with the return there, the original normalizenodes will never be called, and the built in constraints won't get a chance to run their own normalizations but, there's a slight "trick" to normalizing when you do call editor unwrapnodes , you're actually changing the content of the node that is currently being normalized so even though you're ending the current normalization pass, by making a change to the node you're kicking off a new normalization pass this results in a sort of recursive normalizing this multi pass characteristic makes it much easier to write normalizations, because you only ever have to worry about fixing a single issue at once, and not fixing every possible issue that could be putting a node in an invalid state to see how this works in practice, let's start with this invalid document \<editor> \<paragraph a> \<paragraph b> \<paragraph c>word\</paragraph> \</paragraph> \</paragraph> \</editor> the editor starts by running normalizenode on \<paragraph c> and it is valid, because it contains only text nodes as children but then, it moves up the tree, and runs normalizenode on \<paragraph b> this paragraph is invalid, since it contains a block element ( \<paragraph c> ) so that child block gets unwrapped, resulting in a new document of \<editor> \<paragraph a> \<paragraph b>word\</paragraph> \</paragraph> \</editor> and in performing that fix, the top level \<paragraph a> changed it gets normalized, and it is invalid, so \<paragraph b> gets unwrapped, resulting in \<editor> \<paragraph a>word\</paragraph> \</editor> and now when normalizenode runs, no changes are made, so the document is valid! 🤖 for the most part you don't need to think about these internals you can just know that anytime normalizenode is called and you spot an invalid state, you can fix that single invalid state and trust that normalizenode will be called again until the node becomes valid empty children early constraint execution one special normalization executes before all other normalizations and this can be important to keep in mind when writing your normalizers before any of the other normalizations can execute, slate iterates through all element nodes and makes sure they have at least one child if it does not, an empty text descendant is created this can trip you up when you have custom handling when an element has no children for example, if a table element has no rows, you may wish to remove the table; however, this will never happen because a text node would automatically be created before that normalization could run incorrect fixes one pitfall to avoid is creating an infinite normalization loop this can happen if you check for a specific invalid structure, but then don't actually fix that structure with the change you make to the node this results in an infinite loop because the node continues to be flagged as invalid, but it is never fixed properly for example, consider a normalization that ensured link elements have a valid url property // warning this is an example of incorrect behavior! const withlinks = editor => { const { normalizenode } = editor editor normalizenode = entry => { const \[node, path] = entry if ( element iselement(node) && node type === 'link' && typeof node url !== 'string' ) { // error null is not a valid value for a url transforms setnodes(editor, { url null }, { at path }) return } normalizenode(entry) } return editor } this fix is incorrectly written it wants to ensure that all link elements have a url property string but to fix invalid links it sets the url to null , which is still not a string! in this case you'd either want to unwrap the link, removing it entirely or expand your validation to accept an "empty" url == null as well implications for other code sequences of transforms may need to be wrapped in editor withoutnormalizing docid\ hy2ugai1fnvsaa53xavyp if the node tree should not be normalized between transforms this is frequently the case when you unwrapnodes followed by wrapnodes for example, you might write a function to change the type of a block as follows const list types = \['numbered list', 'bulleted list'] function changeblocktype(editor, type) { editor withoutnormalizing(editor, () => { const isactive = isblockactive(editor, type) const islist = list types includes(type) transforms unwrapnodes(editor, { match n => list types includes( !editor iseditor(n) && slateelement iselement(n) && n type ), split true, }) const newproperties = { type isactive ? 'paragraph' islist ? 'list item' type, } transforms setnodes(editor, newproperties) if (!isactive && islist) { const block = { type type, children \[] } transforms wrapnodes(editor, block) } }) }