Feature request: adding dangerouslySetOuterHTML (or HTML-comment component)

[FibreFoX]

Currently there is only the option to have dangerouslySetInnerHTML, but there is no way to create a raw HTML output (like a HTML comment).

For the background where I'm heading to with my feature-request:
I am tinkering with ReactJS (latest version 16.9.0) as some kind of static website generator where ReactJS should be used as the "templating engine". As I do not want to run a nodejs-server, or React at all on the resulting website, SSR is no option for me (and please don't advocate me to use SSR).

As I am using renderToStaticMarkup of the react-dom/server, I can not use the existing ways like manipulating the "DOM"-node, because componentDidMount and useEffect do not work here.

For reference, I tried these tricks without luck (please ignore the asked question on SO, I only talk about the code of the given answers):

• useEffect: https://stackoverflow.com/a/56118306/1961102
• componentDidMount: https://stackoverflow.com/a/41131326/1961102

This topic was asked in some different ways, but not in combination with outerHTML. I think these issues might be related to this:

A way to return raw HTML from an unmounted component?
#7374

What does dangerouslySetInnerHTML prop do? How is it achieved?
#14509

What is the current behavior?

There is no way.

What is the expected behavior?

If possible, I would like to have a way without having to deal with any "workaround"-construct

<React.RawText text={"<!-- some HTML comment -->"} />

If possible, I would like to have a way without having to deal with a <div />

<React.Fragment rawUnsafeHTML={{__html: "<!-- some HTML comment -->"}} />

Otherwise by using a div as some kind of "transport-object"

<div dangerouslySetOuterHTML={{__html: "<!-- some HTML comment -->"}} />

[bvaughn]

I think this issue should be an RFC:
https://github.com/reactjs/rfcs

[SkReD]

This relates to #12014

[bvaughn]

I think #12014 should probably be rolled into the same RFC. The RFC process encourages thoroughly exploring a proposed API change, considering alternative proposals, etc.

I'm going to close this issue (in this repo) and suggest you create an RFC following the process outlined here.