React renders differently on server and client.

[vlinder]

I have read #3152 and #3879 but this seemed like maybe another but related problem.

When the browser tries to bootstrap React and rerender the page I get this warning.

Warning: React attempted to reuse markup in a container but the checksum was invalid. 
This generally means that you are using server rendering and the markup generated on 
the server was not what the client was expecting. React injected new markup to compensate 
which works but you have lost many of the benefits of server rendering. Instead, figure 
out why the markup being generated is different on the client or server:
 (client) e6zyboqo.1.2.1.0.1">"This is a
 (server) e6zyboqo.1.2.1.0.1">"This is a test

Apart from the case that it is unnecessary to escape the quote it seems to render differently on the server and browser. This is just static content so I don't really understand why?

The markup to render the element is like this.

<p><strong>Next:</strong>"This is a test"</p>

How come it's rendered different?

[zpao]

This is likely a red herring, the warning here didn't do the best job of detecting differnces like this, but we've improved it on master. Can you try with the latest betas and see if it still repros?

[zpao]

Or rather, it would still report that something is different, but it should point you at the actual difference and not a random encoded entity (see other discussion in #4608)

[mridgway]

Posted this in my issue as well:

It turns out that Chrome now has Object.assign support and the object-assign package will fall back to using the native method. The key ordering is different when using Object.assign vs. object-assign's polyfill.

[sophiebits]

That's weird, I would expect both to use the enumeration order.

[mridgway]

I have traced it down to React.__spread when used as <Foo ...props> messing with the enumeration order of props. So actually the problem may not be within Object.assign, but with React.__spread changing the underlying structure. From what I can tell, it's just using for..in which may behave differently in node 0.10 and Chrome.

[sophiebits]

Yeah, that should just use this for/in loop: https://github.com/facebook/react/blob/master/src/shared/stubs/Object.assign.js#L37.

[mridgway]

If I switch out the <Foo ...props> with React.createElement(Foo, props) or React.createElement(Foo, objectAssign({}, props)) (from object-assign package) it works fine.

[mridgway]

Appears to be a bug in v8 with getOwnPropertyNames which is used by object-assign. They have marked the issue as WorkingAsIntended unfortunately. I also created an issue against object-assign since this issue arose when they switched from using Object.keys to Object.getOwnPropertyNames.

[sophiebits]

Good sleuthing.

[armandabric]

I'm facing to this issue. Any news on it?

My server generate: foo'bar and my client foo'bar.

[zpao]

@Spy-Seth your issue is unrelated. Make sure you have charset as utf-8 and if that doesn't resolve it please work it out elsewhere or file an issue if you can pinpoint a bug in React

[armandabric]

My page is already interpreted in utf8 <meta charSet="utf-8" />. And do not really see a difference between this issue and mine.

[shouze]

@zpao could this be caused on server side by server not having locales generated for utf-8, only POSIX ones?

[zpao]

@Spy-Seth if you read the rest of the issue, I said the entity piece was probably a red herring and then the original reporter never responded. The rest of the discussion is about ordering of attributes (with some other discussion in #4608). If your issue is actually about encoding, then please file a new issue with a complete example to reproduce. It's otherwise impossible to help.

[zpao]

@spicyj @mridgway what was the outcome here - did we need to make a change to React.__spread?

[mridgway]

Our issue turned out to be an issue with the object-assign package switching to using getOwnPropertyNames which returns keys in the wrong order when the object's key become too large. See https://code.google.com/p/v8/issues/detail?id=3056. In version 4.x of object-assign they moved away from using getOwnPropertyNames.

Object.assign in Chrome also has the same issue, so if you're using a polyfill on the server and Chrome's native Object.assign on the client, then you will hit the checksum issue. Some polyfills are now checking the enumeration order and overriding the native version if it fails. See object.assign and core-js(used by babel's polyfill).

[lalau]

Is this issue about mismtach caused by character encoding (@vlinder) or attribute ordering changed by object.assign (@mridgway)?

I am seeing a similar issue as @mridgway that in some cases the props key ordering is changed by object.assign and then by using the spread operator to specify them causes the server the client to render the attributes in different order.

Since the spec doesn't specify the ordering the keys in an object, it seems pretty fragile that we take the attribute ordering into account when determining if there is a mismatch. The other way is to have the spread operator returns a consistent ordering, but not sure how you can do that except doing a sort on the keys, which is pretty costly.

[vlinder]

@ktslwy For me it was always character encoding. As my original message pointed out. Did not have any time to create a minimal test case though. And I haven't been seeing this error in a while. So prabably a newer version has corrected the problem.

[Download]

@mridgway

Our issue turned out to be an issue with the object-assign package switching to using getOwnPropertyNames which returns keys in the wrong order when the object's key become too large.

Ah!! That sounds like a really good reason for me seeing this warning:

Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
(client) ut" id="textfield-" value="" type="text"
(server) ut" id="textfield-" type="text" value=""

I have an isomorphic app so I can't see a reason key ordering should be different.... except for what you are saying here. Thanks!

[eliseumds]

@Download same thing here with React 15.0.2.. This is the diff: https://www.diffchecker.com/zvlfqz5n.

[sophiebits]

Can anyone seeing wrong attribute orders re-install and make sure you have [email protected]? That should fix the issue.

[eliseumds]

@spicyj that works for me. Thanks.

[Download]

Thanks @spicyj I uninstalled React 15.0.1 and I installed React 15.0.2 and this seems to have fixed it.

[gaearon]

I'll close since the fix has been out for a while, and we also don't care about the prop order in 16.