Significance of Schema Node Order

I was creating a Schema from scratch and had mistakingly assumed that, because nodes and marks are defined as objects with the type names mapping to the type definitions, order would be irrelevant as long as doc and maybe text are included. I was wrong. And in the process of diagnosing, I learned about OrderedMap. But I remain unclear on two things:

What impact does the order of node types in the spec have on editor behavior?

It seems that the first type is always the default type, and likely needs to be the doc definition.

  • Is this the case?
  • How does the order of subsequent definitions in the order influence behavior?

What node types and mark types are required in the specs?

I searched for information on these two questions in the docs, StackOverflow, here on Discuss, and elsewhere, but came up short. If these have been answered in some form somewhere, I would appreciate being pointed in the right direction.

1 Like

Most importantly, this determines the order in which nodes are tried as filler nodes when generating content to satisfy schema constraints. If you for example create an empty document with createAndFill, and the document content is specified as "block+", the editor needs some block to create valid content, and it’ll pick the first block node (that doesn’t have attributes without default values) in the order of the schema. Similar, when trying to insert a node in a place where it isn’t directly allowed, the editor will try to create wrapper nodes for it, and again the order in which nodes are tried is the schema node order.

This order also determines the default order in which parse rules are tried, which can be overridden with the priority option.

You’ll want at least doc (a top-level node) and text. If your top-level node allows text as child, that’s all—that would give you an editor that only supports a single block of plain text. Anything else is optional.

2 Likes

Much appreciated. Thank you.