Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: dangerouslySetInnerHTML as a return value #9483

Closed
iamdustan opened this issue Apr 21, 2017 · 5 comments
Closed

Feature Request: dangerouslySetInnerHTML as a return value #9483

iamdustan opened this issue Apr 21, 2017 · 5 comments
Labels
Resolution: Stale Automatically closed due to inactivity Type: Feature Request

Comments

@iamdustan
Copy link
Contributor

I haven’t fully thought through this yet, so hoping for some feedback on whether it is viable or breaks too many assumptions.

The goal is to create an escape hatch that would support rendering to conditional comments, alternative method for web components, and other unknown and probably bad ideas.

Something along the lines of:

const DangerousComment = ({children}) => ({
  dangerouslySetInnerHTML: {__html: `<!-- ${children} -->` }
});

ReactDOMServer.renderToString(
  <head>
    <DangerousComment>
      {"[if lte IE 9]><script src='/public/media.match.js'></script><![endif]"}
    </DangerousComment>
  </head>
); // <head><!--[if lte IE 9]><script src='/public/media.match.js'></script><![endif]--></head>
const WebComponent = ({children}) => ({
  dangerouslySetInnerHTML: {__html: `<!-- ${children} -->` }
});
ReactDOM.render(() => (
  <WebComponent>`
    <app-toolbar arbitary-prop="sure-y-not">
      <div main-title>Web Components!</div>
    </app-toolbar>
  `</WebComponent>
), document.body.firstChild);

The first example is the one I’m more interested at this point in time. The benefit here is this could work on both the DOM and server renderer without userland hacks like https://nemisj.com/conditional-ie-comments-in-react-js/ or componentDidMount ref replacement (client only, I believe?).

A couple initial problems I see with this are (may or may not be solvable/avoidable with slight tweaks):

  • returning an arbitrary object render which isn’t supported
  • how will unmounting this work?

Alternative proposal:

Introduce a new DOM-renderer primitive <comment /> or <dangerousComment /> (to follow a similar approach to dangerouslySetInnerHTML clearly indicating the caveats that come with rendering comments). This alternative solution only solves the conditional comment issue above.

@kidwm
Copy link

kidwm commented Dec 19, 2018

Or could we have something like this way since React 16 component is able to return string:

<div
        dangerouslySetInnerHTML={<DangerousHTMLString />}
/>

@stale
Copy link

stale bot commented Jan 10, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jan 10, 2020
@stale
Copy link

stale bot commented Jan 17, 2020

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

@stale stale bot closed this as completed Jan 17, 2020
@zomars
Copy link

zomars commented May 29, 2022

This is still a valid issue and we cannot use div inside head tags.

@yairEO
Copy link

yairEO commented Jul 5, 2023

please someone save this issue from getting lost..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Stale Automatically closed due to inactivity Type: Feature Request
Projects
None yet
Development

No branches or pull requests

5 participants