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

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

Closed
johnnysprinkles opened this issue Oct 5, 2017 · 7 comments · Fixed by #11119

Comments

@johnnysprinkles
Copy link

johnnysprinkles commented Oct 5, 2017

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
Copy link
Author

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

@syranide
Copy link
Contributor

syranide commented Oct 5, 2017

👍 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
Copy link
Contributor

syranide commented Oct 5, 2017

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
Copy link
Collaborator

gaearon commented Nov 3, 2017

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
Copy link

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
Copy link

mihaiserban commented Jun 20, 2018

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

server renders &gt; while client >

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

@gaearon
Copy link
Collaborator

gaearon commented Jun 20, 2018

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.

@facebook facebook locked as resolved and limited conversation to collaborators Jun 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants