noscript contents cause invariant violation

[matthewwithanm]

When using server rendering, putting an <img> in a <noscript> seems to invariably cause an invariant violation (it can't find the image).

I believe this is because, to the JS enabled browser, the noscript content looks like CDATA.

This can be worked around by using dangerouslySetInnerHTML to actually set the contents to an HTML string, however, you can't nest components with this approach.

[matthewwithanm]

Now that we have renderComponentToStaticMarkup, maybe the best solution for this is just to do:

<noscript dangerouslySetInnerHTML={{__html: React.renderComponentToStaticMarkup(c)}} />

where c is the component you want to render for people without JS.

[sophiebits]

We should just make noscript do this automatically, sort of like our existing wrappers for input, select, and textarea. Want to take a crack at it?

[matthewwithanm]

Sure. I'll try to get a PR in soon.

[andygeers]

I'd love it if somebody could revisit this issue - it's a real pain to have to use the workaround

[syranide]

Related #1905 ... should we even set the content of <noscript> client-side? (Or technically even render it when React is able to) It's a perf hit and I can't think of a reason you would ever care about the contents of the <noscript> when client-side?

PS. I feel like there's something dirty about renderToStaticMarkup happening behind the scenes. Wouldn't it make more sense to just disallow children and if people want the implicit behavior it should be wrapped up in a custom component?

[matthewwithanm]

Yeah, I think I suggested ignoring <noscript> contents on the client in #1253, but it would cause checksum issues with SSR if I'm not mistaken.

As for rendering to a string, it may be dirty but, in my opinion, it's the acceptable kind of dirtiness since it protects the user from the inherent complexity of dealing with a wonky browser bug. I guess you could argue that <noscript> should have a CDATA child (that just happens to be a string of HTML) and not actual DOM children, so it's outside the purview of React, but that seems to make it largely useless without that custom component.

[syranide]

@matthewwithanm Oh right, yeah, reusing client-side would require a special flag internally which would use server-rendering rules when constructing the initial markup.

[defrex]

For future searchers, here is this workaround wrapped up into a component. In this case set up as an ES6 CommonJS module that relies on the constant process.browser. Adapt as needed.

const React = require('react/addons');

module.exports = React.createClass({
  displayName: 'NoScript',
  mixins: [React.PureRenderMixin],
  render() {
    if (process.browser)
      return <noscript/>;
    else
      return <noscript dangerouslySetInnerHTML={
        {__html: React.renderToStaticMarkup(this.props.children)}
      }/>;
  }
});