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)}
      }/>;
  }
});

[Jpunt]

I'd like to use this workaround, but it seems to be deprecated:

Warning: React.renderToStaticMarkup is deprecated. Please use ReactDOMServer.renderToStaticMarkup from require('react-dom/server') instead.

I'm guessing that ReactDOMServer is not available on the client. So, now what?

[benkeen]

@Jpunt me too. Being able to convert a React component to static markup on the client came in handy sometimes.

[jimfb]

@Jpunt @benkeen

ReactDOMServer.renderToStaticMarkup() is available on the client side if you include <script src="https://fb.me/react-dom-server-0.14.7.js"></script>

[benkeen]

@jimfb you da MAN. Thanks, that's very helpful!

[srcspider]

noscript is a very critical component even for a javascript-dependent application. If anything even the utility it provides (eg. "you need javascript to use this page") is even more essential to javascript-only pages then normal ones.

@Jpunt @jimfb ( /cc @benkeen )

Maybe there are uses for rendering static markup on the client but noscript is not one of them.

If react is running then the noscript is clearly useless now since javascript is enabled in the browser and hence the contents of the noscript may as well not exist. The only reason a noscript tag even makes sense to generate (instead of just returning null) is to avoid an invariant error because react expects it from the server side.

var React = require('react');

var is = {
    browser: require('lib/is/browser')
};

var ReactDOM;
if ( ! is.browser()) {
    ReactDOM = require('react-dom/server')
}

var NoScript = React.createClass({

    mixins: [ React.PureRenderMixin ],

    render: function () {
        if (is.browser()) {
            return <noscript/>;
        }
        else { // on server
            return <noscript dangerouslySetInnerHTML={
                { __html: ReactDOM.renderToStaticMarkup(this.props.children) }
            } />;
        }
    }

});

module.exports = NoScript;

You'll want to alias the react server code to resolve to empty module since it's unlikely you're bundler will figure it out on it's own; not with out some other rules in place anyway. If you use webpack add the following to your configuration:

resolve: {
    alias: {
        "react-dom/server": "empty-module"
    }
},

And make sure you have empty-module on your load paths. I recommend you do npm i -D empty-module, since a dependency is clearer (and cleaner) then an empty file in the project.

[wchargin]

@srcspider: Could you explain why you choose to render an empty noscript on the client instead of the same noscript with dangerouslySetInnerHTML? When I try to do this I get a server-side rendering mismatch

 (client) t data-reactid="25"></noscript><div clas
 (server) t data-reactid="25">&lt;div&gt;&lt;secti

which totally makes sense.

Rendering the static HTML in all cases works for me, and should be fine performance-wise with the pure-render decorator.

[BabakMN]

I think this issue should be highlighted somewhere on the documentation.

The following seems to work well for me both on client and server (thanks to people above):

Noscript.js

import React from 'react';
import ReactDOM from 'react-dom/server';


export default function Noscript(props) {

    // https://github.com/facebook/react/issues/1252

    const staticMarkup = ReactDOM.renderToStaticMarkup(
        props.children
    );

    return <noscript dangerouslySetInnerHTML={{ __html: staticMarkup }} />;

}

Usage:

import Noscript from './Noscript.js';

<Noscript>
   <div className="noJavascript">
      <div>
         <p>
         Your browser has disabled Javascript. Please note this website requires Javsacript to function correctly.
         </p>
      </div>
   </div>
</Noscript>

[wchargin]

@BabakMN This is a good first-order approximation (and I use it), but it has the severe limitation that you cannot nest Noscripts; see #6204. This destroys local reasoning. If this approach is highlighted in the documentation, then either #6204 must be either fixed or the documentation must warn aggressively about this.

[BabakMN]

@wchargin I just dug into #6204, very interesting. I agree with you that squashing the <noscript> tags into one is the better behaviour.

[gaearon]

I believe React 16 doesn’t crash on this anymore, even though it produces a false positive warning.
We’ll track the warning in #11423.