Document that you can't rely on React 16 SSR patching up differences

[bvaughn]

This issue was originally filed by @Tarnadas at facebook/react/issues/10591. There's a lot of interesting discussion there.

PR #116 added some additional clarity to the React 16 blog post by calling out that it's dangerous to have missing nodes on the server render, and they might get re-created with incorrect attributes.

@gaearon suggested in a comment below that a core team member should also create a more in-depth blog post about SSR behavior.

[fumblehool]

@bvaughn Can I work on this issue?

[bvaughn]

This issue is all yours! 😄

I've added an "in-progress" label so that others will know not to start work on the issue. If you change your mind about the issue, no worries! Just let me know so that I can remove the label and free it up for someone else to claim.

Cheers!

[gaearon]

I don’t think just adding a sentence to the blog post is enough. Originally, we planned to have a whole separate post about this, but @sebmarkbage didn’t find the time to write it.

This is going to keep confusing people over and over, and this behavior should be described somewhere in detail, together with the rationale for it.

[gaearon]

We should probably do a post after releasing 16.1.0 that introduces the “suppress warning” feature and explain the new behavior in more detail there. Then we can link to that post from the hydrate API doc.

[sergio-toro]

@gaearon I totally agree on writing a blog post. I'm just updating our app to 16 and I ran into the SSR breaking design when generated markup does not match.

[bvaughn]

@gaearon Can you please update the title and description of this issue to be more reflective of what you're looking for then? (Or alternately, just open a new issue)

[gaearon]

I'm not sure how to update the title. It still describes what I want to happen. I just don't think adding a sentence that's easy to miss to release notes counts as documenting a fundamental change in behavior which hasn't ever changed before (and which people often rely on).

My suggestion is in #25 (comment) but perhaps there are other solutions? I don't want to prescribe a particular one. For new users, it should be something that is easily visible next to our hydrate API reference. For old users, it should be something they can point to and share to educate the community (blog post sounds like a good format). It should include an explanation for why we changed this, and the exact things you can and cannot rely on.

[gaearon]

For example, my blog post about attributes provided such rationale and migration advice for the attribute change. It seems like we're not getting issues about the new behavior which means it was well understood.

On the other hand we've gotten five or six issues about SSR behavior. Even with that new sentence, it is too easy to miss or get confused. So it probably deserves its own blog post.

I'm not saying this issue is necessarily actionable for someone else. I see it most as todo for ourselves. No one has more context on this than us. But I want to keep it open until we fix it.

[bvaughn]

Sure, the title's fine I guess. It just seems that I incorrectly summarized what we're looking for and it seems like you have a better idea than I do, and so it may save external contributors time and confusion if we update the description to more clearly reflect what we're looking for. 😄

Even if it's just "a core team member should write a blog post".

[bvaughn]

I took a stab at updating the description and the labels.

[matthewmueller]

I've been trying to understand what it means for the server & client-side mismatch to be dangerous:

it’s dangerous to have missing nodes on the server render as this might cause sibling nodes to be created with incorrect attributes.

Is there any test or example to show an incorrect rendering?

[gaurav5430]

Just stumbled into this issue in my nextjs app.
Took me some time to find the original discussion and then this issue.

Any news about the blog post?

[yangshun]

I think this issue can be closed now as the docs on hydrate() seems to document this behavior well.

[gaurav5430]

the description for hydrate in the docs does seem to touch on this point, but would be a lot helpful if it talks about some of the pitfalls that can happen because of this. In my case, due to conditional rendering, the order of components was different on server vs client and while patching up hydrate changed the dom structure on the client