Why is renderToString(<div/>) generating different id's and checksums on each call? Is this a defect?

[jeffbski]

I was trying to figure out why my isomorphic rendering isn't matching and thus I began trying to simply code when I realized that even successive rendering of a single div ends up with different checksums and id's??

Can anyone help me understand this?

var React = require('react');
var elem = React.createElement("div", null);
console.log(React.renderToString(elem)); // '<div data-reactid=".2c9xyqo6uio" data-react-checksum="220400958"></div>'
console.log(React.renderToString(elem)); // '<div data-reactid=".27gjxlu5fk" data-react-checksum="-46789451"></div>'

var assert = require('assert');
assert(React.renderToString(elem) === React.renderToString(elem)); // fails

I expected the checksums to be the same and probably the event id's (but I don't know how it determines those).

Does this appear to be a defect?

[jeffbski]

I believe that I may understand the issue.

Apparently when rendering on the server it uses random id's and the checksum will be different since it uses these id's in the calculations. However apparently the browser mounting code can determine somehow that the tree matches and just mount with event listeners.

If I make the props not match, then I do see the expected warning in the console log that "Warning: React attempted to reuse markup in a container but the checksum was invalid.", so I guess you can't manually look at things and know whether they will work or not. If you see the warning then it isn't working.

If anyone wants to elaborate on this more, that would be great, otherwise we can probably close this issue.

[jimfb]

What version of React are you using? Your data-reactids look a little janky to me, so my guess is you're using an out-of-date version?

When rendering to a string, React generates the full markup string (including a data-reactid to uniquely identify the render root), and calculates the adler32 checksum of that string, and then appends the checksum to the root element. The client can do the same, and compare the two checksums - they should match. This is arguably a bug (but maybe a low priority one) because the data-reactid doesn't technically need to match in order for the markup to be compatible.

You are rendering twice, thus two different render roots. Your issue comes from the fact that each render roots have a unique data-reactid, and since the checksum is calculated across the markup string, this effectively means that each call to renderToString has a unique checksum. As long as your render roots have matching data-reactids, their checksums should match too.

I'm going to close this out as not-a-bug, since this is expected/known behavior. At some point, it may make sense to have the checksum calculated without considering the root's data-reactid but this could have performance considerations (our current checksum implementation is super fast/simple), and so such a change is not on our roadmap.

cc @sebmarkbage for situational awareness.

[jeffbski]

@JSFB I am using react@0.13.0-rc1

Thanks for the clarifications, though.

[jimfb]

Interesting. Ok, apparently our data-reactids are now generated in a way other than incrementing from zero (we used to just increment an integer). Good to know. The rest of the answer still applies.

[zpao]

We do increment from zero when rendering on the client.

We generate a random number on the server.

The idea behind this is that on the client there is a single React and we know everything (though that has proven to be a source of problems when there are multiple Reacts). On the server we don't know about everything nor how it will be generated (you could imagine 2 parallel processes generating a page) so we can't start at 0 and increment, you'll get clashing keys very quickly. So we use random numbers. There's still a small chance of collision but it's probably fine for now.

[jimfb]

@zpao Why do the algorithms differ? Why not always use random?

[zpao]

More predictable behavior perhaps. Adding 1 is faster than Math.random() and you can be much more certain that you won't have collisions. In general autoinc a known unique int is fast and cheap and guaranteed unique (to 9007199254740991: 2^53 - 1). An algo with the same guarantees is expensive and takes up more space (GUIDs are nice but also have 31 chars, sticking that in each DOM node sucks). Another (bad) option would be to always use Date.now() but at microsecond precision you're pretty much guaranteed to collide.

I don't remember if there's much more to it honestly. cc @petehunt @syranide

[syranide]

@zpao Yeah, the only two reasons I can think of for not always using random are overhead and collisions (however unlikely).

Ultimately I want to get rid of data-reactid on DOM nodes though, but it needs some more core refactoring before that can happen "neatly".

[jimfb]

I was going to say that I'd like to see us choose a single algorithm, but I like @syranide's idea even better.

[jeffbski]

@jimfb @syranide agreed.

[syranide]

@JSFB For posterity; #1570. It's very much possible to do today, but there are some bugs/missing things in core which prevents doing it for "for real". It's also easy to just reconstruct reactid's for pre-rendered markup.

[qwtel]

Just wanted to let you know that this is also causing trouble with autogenerated ETags like in connect/express. Since the reactids are different for every request, the ETag will be different as well.

It's not a big deal though, since custom ETags are the way to get around the renderToString cost anyway.

[syranide]

@qwtel An interesting point, the only reason for it being random is to avoid conflicts with multiple server-side renders on the same page... perhaps the devs will object to the API bloat, but being able to provide a custom react root id would make sense. (In the future this will likely go away altogether)