Doc's TextNode goes as a content to the wrong node

1

The doc of my editor has a required custom node editorTitleView. Here is how i wrote its definition

nodes.doc.content = ‘editorTitleView selectMenu? block+’;

The editorTitleView’s parseDOM requires not only editor-title as a tagName but also editorTitleCls as its class.

parseDOM: [
        {
          tag: 'editor-title[class]',
          getAttrs(dom) {
            const classList = dom.getAttribute('class');
            if (classList && !classList.includes('editorTitleCls')) {
              return false;
            }
            return {
              class: classList,
            };
          },
        },
      ],

Now this is how i parse the initial content and i create the doc that will be passed to the editor’s view state later on

const initialContentDiv = document.createElement('div');
initialContentDiv.innerHTML = 'This is an initial simple string content to be passed to the editor';
const doc = DOMParser.fromSchema(ProsemirrorEditorSchema).parse(initialContentDiv);

new EditorView(pmEditor, {
      state: EditorState.create({
            schema: ProsemirrorEditorSchema,
            doc,
            plugins,
     }),
});

The problem i always get is that simple string passed to the doc will be always taken as the editorTitleView’s own content while it’s supposed to be appended to the doc content (in its own pragraph) just after the required editorTitleView node which itself should be empty: This is the doc structure just after its creation :

{
    "type": "doc",
    "content": [{
        "type": "editorTitleView",
        "content": [{
            "type": "paragraph",
            "content": [{
                "type": "text",
                "text": "This is an initial simple string content to be passed to the editor"
            }]
        }]
    }, {
        "type": "paragraph"
    }]
}

Why does it happen and how i can prevent this ?

2

Because when the DOM parser looks to insert the text, it’ll look at the schema to determine which nodes can be created at the current position, and the only node that’s allowed at the start of a document is a title.

You can’t, really, on the DOMParser level. Though running your own pre-processing pass on the DOM you want to parse to inject a title should be easy.

1 Like
3

I forgot to mention that the parseDOM doesn’t even run at all. The parser just takes the first node and inserts it inside the required first node to be created even it doesn’t respect the node’s specification. I think the ideal behaviour would be to generate the required node but to leave it empty if there isn’t its equivalent in the doc content or if its equivalent is empty too. Maybe this can be an improovement in the future? Thanks for the answer anyway.

4

If there’s no DOM element matching the tag property, then indeed, your rule doesn’t run. The node is created as a required parent for the text here, not matched via your rule.

In which way does the resulting document here not respect the node’s specification?

5

Hmm, ok I got it for the parseDom not running as there is no tag. But if there is no tag at all then it’s more logical to generate an empty node (as it’s required) and prepend it to the doc and not to suppose that the first parsed html node must be its content (it’s that first html node which doesn’t respect the spec i meant - as it doesn’t have the tag!)