Hard_break from basic schema creates two <br> nodes

I was inspecting one of the basic demo application to identify the behaviour of the hard_break as i have a similar use case in the project I am working on.

It appears to me that the hard_break adds two <br> nodes. I would rather expect just one <br> to be added.

Is there a way to create a custom node schema or tweak existing behaviour, which just adds a single <br> under a paragraph?

hard_break schema snippet from prosemirror basic schema

hard_break: {
inline: true,
group: "inline",
selectable: false,
parseDOM: [{tag: "br"}],
toDOM() { return brDOM }}

It adds only one node to the document. The extra <br> you see in the DOM is just there in the editable view to make sure the content renders properly (without it, many browsers will hide the trailing <br>), and isn’t part of the actual document.

Ok. that seems reasonable. But is there a way where i can override that behaviour so that I can have more control on the doc render? As I would like to display a single
when my document has a
in it.

Yes, I did check, it does not modifies the actual document nodes.

1 Like

The rendering inside the editor is hard-coded to include that extra break. How you render it outside of the editor is entirely up to you.

So I was going through your comment again. What i was looking for was is there a way where i can suppress rendering inside the editor to not to add the br by itself?

As currently, I have created a custom inline tab node to my schema, which basically would render tabs behaviour inline with rest of the the text node. But the issue i am facing is that due to addition of br in editor rendering, it splits my paragraph into two lines when there is an inline tab in between text.

My schema node hierarchy is something like this.

   tab (i use span in toDom with some width to show tab spaces)

I need to have above structure to add custom spaced tabs in between text, for example:

1.     This line has a tab between number and rest of the text

Strange. The tab-inserting behavior only looks at the last node in the paragraph, and if that is a regular text node, it should not occur. There may be something else going wrong here. Can you set up a minimal demo that shows the issue?