react: Need a hook for hydration mismatch

@redonkulus I’m curious how you achieved this using only the attribute. AFAICS, the data-react-checksum attribute is always there, regardless of if there is a mismatch?

@OliverJAsh If the checksum attribute is present then we know the DOM was reused (<= React 15). If its gone, then we know the client re-rendered the whole app. Its simple, but has worked well for us for a few years now.

We too have seen issues in IE based on locale strings, video autoplaying that starts on server rendered markup but then gets re-inited once React on the client starts up (if there is a checksum mismatch), ads that get re-rendered doubling the impression count on markup mismatch. These are major things that require a solution or hook from the library.

I think the trouble we find is that the React team and Facebook do not use React server side so the priority of such issues is lower on the list of other efforts the team is solving. I believe an RFC would be the correct approach, but we need to know what the solution would look like.

@sebmarkbage @gaearon can you help provide a direction on an approach that would be acceptable? We do not know the ins and outs of the React codebase like yourself, so any information helps.

Using the patch I mentioned for React v15 in https://github.com/facebook/react/issues/11189#issuecomment-367752926, we’ve been able to identity many different checksum errors in production that we wouldn’t have been able to otherwise. Usually these are checksum errors in browsers we can’t test locally, or they happen under some edge case that we just didn’t catch when testing locally.

For example, just today I discovered a checksum error in IE and Edge that happens because JS math calculations are different in Node vs IE/Edge, leading to different values for an inline style:

(5342 / 3561) * 100
// => Node: 150.01404099971919
// => IE/Edge: 150.01404099971918

I would have never discovered this without error reporting in production.

Not having a way to report these errors in v16 is a real blocker for us upgrading. We need to be able to monitor these errors when they happen, because they inevitably will.

From this issue it sounds like I’m not alone in needing this. If anyone from the React team could suggest to me how this might work in React v16, I’d be happy to do the work to put together an RFC.

Seems like this is the best we can offer:

Monkey patching console.error seems like the way to do this. Whatever other hooks we expose would end up looking very similar to that. We’ve talked about an alternative way to intercept warnings in a generic way. Maybe that can be a way.

Can someone elaborate on what the above actually means and perhaps hint towards an example? Page experience is becoming a bigger deal than ever and in fact Google will start prioritizing it in search. I help support a website that uses Next.js for server-side rendering and it’s apparent that we have a mismatch between client and server renders. I’m having a difficult time in debugging where this mis-match is and if there are more than one. I believe our issue is killing our core Web Vitals as seen in the screenshots below. I’ve perused Next.js showcase of websites and most of them appear to suffer from the same issue. Would appreciate any detailed suggestions on how to debug… but more specifically clarification on the comments I’ve referenced at the top.

Before Next.js hydration

Next.js hydration

I know it’s hardly useful to ping on an issue, but it’s been awhile, yet this does seem like there is a genuine requirement here. The upgrade to React 16 means we’re losing our checksum/mismatch error reporting, which has been very useful in helping us identify all sorts of weird but frequent bugs.

@sebmarkbage @gaearon I’d like to echo @redonkulus’s request, could we get some direction from the React team on this?