Trying to understand how rehypeReact inserts custom React nodes

[ChristopherPAndrews]

I am parsing some Markdown and I want to include a custom React component. I am using this:

 .use(rehypeReact, {
      createElement,
      Fragment,
      components:{
        test:()=><div>Testing...</div>
    }})

My markdown looks like this:

<test></test>

After 1

<test />


After 2

The HTML that is generated is

<p><div>Testing...</div></p>
<p>After 1</p>
<div>Testing...</div>

So, if I use open and close tags, the component is wrapped in a paragraph tag. If I use a self-closing tag, it appears to be inserted as a fragment without the wrapping, BUT nothing after the tag in the markdown is included.

I am trying to put a component that includes elements that should not be inside of a <p>, and it has no children, so a self closing tag seems to make sense, but it is a problem if nothing else shows up on the page.

Am I doing something wrong, or have I uncovered a bug?

[ChristianMurphy]

Welcome @ChristopherPAndrews! 👋
Yes, the behavior is expected, it's how HTML works.
An example with <div> which illustrates what the expected behavior is:

<div/><span></span><span></span>

This will be parsed into:

• html
  • head
  • body
    • div
      • span
      • span

The trailing U+002F (/) in a start tag name can be used only in foreign content to specify self-closing tags. (Self-closing tags don't exist in HTML.) It is also allowed for void elements, but doesn't have any effect in this case.

https://html.spec.whatwg.org/multipage/parsing.html#parse-error-non-void-html-element-start-tag-with-trailing-solidus

<test/> is not self closing (these exist in XML, not in HTML) nor is it a void element in HTML.
The parser see it as a start tag, which is unclosed, and autocloses it at the end of the document.
Meaning After 2 is considered inner content of <test>, and is replaced by your custom components.test element.

[ChristopherPAndrews]

Okay, that does explain where the rest of the markdown goes. I am too used to working with JSX, I guess. MDX is possibly a way to go, but this is a toy example ripped out of something much larger and it would be a challenge to special case this or re-engineer it.

it is still curious to me that one gets wrapped in a <p> and the other one doesn't. If <test></test> was inserted inside a React.Fragment or a <div>, that would be fine. Is there a reason why the <test></test> is wrapped in a <p> (or some way to change it)? If it was a React.Fragment or a <div> then the current solution would be fine (as it is, it "works", the browser just complains a lot behind the scenes).

[ChristianMurphy]

The first is an HTML inline, which gets wrapped in a paragraph. https://spec.commonmark.org/0.30/#raw-html
The second is an HTML block, which does not get wrapped in a paragraph.
https://spec.commonmark.org/0.30/#html-blocks

[ChristopherPAndrews]

I can see that one is being treated as inline and the other as a block. I'm still not quite sure why... But, the more pressing question is if there is a way to convince it to treat the first as a block so it doesn't get wrapped in a paragraph.

[ChristianMurphy]

I can see that one is being treated as inline and the other as a block. I'm still not quite sure why

Short version there being newlines inside the content makes it a block.
The spec linked above gives more specifics.

way to convince it to treat the first as a block

No, remark and rehype will not diverge from the spec.

so it doesn't get wrapped in a paragraph

You can make a plugin to change content structure.
https://unifiedjs.com/learn/ explains plugins.
If you are looking for an example of how it could look, see how this plugin unwrap images https://github.com/remarkjs/remark-unwrap-images

[ChristopherPAndrews]

Got it. With that in mind, there is a way to convince the system not to treat it as inline -- just use

<test>

</test>

in the markdown. It isn't the prettiest thing, but it appears to be enough to convince remark and rehype that this is a block element. If I get inspired later I may write a plugin like unwrap-images, but in my scenario where I have complete control of the markdown, this will work for now.

Thank you for the help.