SSR: ReactDOM client and server handling newlines differently causing mismatch warnings

[johnnysprinkles]

Bug report:

I noticed a "Warning: Text content did not match" warning on certain pages of my isomorphic React app, using React and ReactDOM 16.0.0.

After boiling it down to a simple test case it seems that different kinds of newlines are handled differently, some failing to match. If I do:

let test = 'foo\nbar';
...
<div>{test}</div>

Everything is fine, no mismatch error and the words are separated in the browser.

However if I do:

let test = 'foo\rbar';

I get:

Warning: Text content did not match. Server: "foo
bar" Client: "foo
bar"

Except in the JS error console the second foobar reads as one word. This seems to be a Chrome issue, mishandling single \r carriage return. Try x = 'a\rb'; and it echoes that string to the console as one word. In the browser I see "foobar" as one word.

More importantly though if I do Windows newlines:

let x = 'foo\r\nbar';

The result in my app is:

Warning: Text content did not match. Server: "foo
bar" Client: "foo
bar"

Which definitely seems like a bug in React's reconciliation logic.

Setup:
Full list of NPM deps:

  "dependencies": {
    "babel-plugin-transform-object-rest-spread": "6.26.0",
    "babel-preset-es2015": "6.24.1",
    "babel-preset-react": "6.24.1",
    "babel-register": "6.26.0",
    "express": "4.15.3",
    "json-bigint": "0.2.3",
    "moment": "2.18.1",
    "pm2": "2.7.1",
    "react": "16.0.0",
    "react-dom": "16.0.0",
    "request": "2.81.0",
    "request-promise-native": "1.0.4"
  },

This is a Node/Express app on Node 8.4.0. Browser is macOS Chrome 61.0.3163.100

Workaround:

Preprocess any text that's user-uploaded content to normalize the newlines.

[johnnysprinkles]

I don't know if this issue exists prior to React 16.

[syranide]

👍 Browsers all normalize the newlines to be \n-based only. So at best, when rendering SSR React should normalize the newlines before rendering to DOM, but if perhaps there's a measurable impact on performance (although I kind of doubt it) and it would be preferable to just perform a less strict run-time check if the text comparison fails. Alternatively, React could also emit a warning if it encounters \r when rendering text but that seems too strict.

cc @gaearon

[syranide]

I'm also fairly certain there are other similar issues with some special unicode codepoints, which the DOM may discard or some browsers could encode differently. EDIT: For one, the DOM will discard \0 (but not in all browsers!).

[gaearon]

React 16.1.0-beta has been released. Please update react, react-dom, and react-test-renderer (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get 16.1.0 out.

[antoninadert]

Hello, I have the same issue, with React 16.2.0

This is when I used HTML escape code inside a render function.

       ` <div > &lt;style&gt; tags </div>`

[mihaiserban]

I have the same error caused by greater char in the css '>'
using react-dom@16.4.1

server renders > while client >

div.ReactTags__tagInput input.ReactTags__tagInputField:focus > div.ReactTags__tags {
    border: solid 1px #828994;
}

[gaearon]

Please file a new issue with a reproducing case. We don't track discussions in closed issues, and new bugs reported there essentially stay unreported.