Need a hook for hydration mismatch

[redonkulus]

Do you want to request a feature or report a bug?
feature

What is the current behavior?
In React 16, the data-react-checksum attribute was removed from the server rendered markup. In previous versions, we used this attribute to beacon checksum mismatches to our log servers to be notified of production issues. With the attribute removed, we have no mechanism to determine if a checksum mismatch occurred.

I'm aware that checksum issues no longer cause the entire DOM to re-render, however, it is still important that we know when they do occur. A typical use case is when we display ads or autoplay video. We want to know if an ad gets re-rendered (double counted) or an autoplay video is interrupted due to React re-rendering the DOM.

Other related bugs/requests:

• Ability to debug checksums in production - Feature Request: Need ability to debug checksum mismatch in production environment #10016

What is the expected behavior?
The solution does not necessarily need to re-introduce the checksum attribute again. It could be some other event, hook, or callback that applications can leverage to handle checksum issues.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

• React 16
• All browsers
• Worked in <= React 15

[syranide]

Isn't intercepting and logging warnings (and errors) enough?

[redonkulus]

@syranide like monkey patching console.error and looking for checksum errors? Ideally there would be a properly supported API from React.

One idea could be in the callback from the React.hydrate call? I believe the callback and already return an error object. Perhaps checksum issues could be exposed that way as well.

[sebmarkbage]

Diffing of attributes and innerHTML no longer happens in the production build so we have no way of issuing this for all possible mismatches. Even for text content we run normalization stuff only in DEV to know whether it actually was a mismatch or not. In theory we could issue some hook for particular mismatches that we actually currently track in production like tag mismatches but it would be very limited since many mismatches doesn't actually end up in different DOM structures.

So you probably have to run the dev build for this to work fully.

A callback to hydrate wouldn't work because we want to be able to asynchronously and lazily hydrate parts of the tree at a time. There is no particular time where we've done all the matching.

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.

[redonkulus]

Thanks for the response @sebmarkbage.

In React 15 today, we do not get the diff in production (as you know), we just know that a mismatch occurred so that we can then run our local dev build to investigate it further. The main concern is just losing the ability to know an error occurred. I'm less concerned with getting the diff in production.

I can try monkey patching, I just don't know if that is the best solution to advocate going forward.

In general, I'm curious how other apps handle this production? Are checksum issues not a concern for most applications? Or because React 16 isolates the checksum issues further down the tree, perhaps its less of an issue?

[lingyan]

Is it possible to attach a data attribute (e.g. data-react-mismatch or some better name) on the altered dom node (only the root one would be enough), so that application code can check for reporting purpose?

[redonkulus]

@sebmarkbage ping

[sebmarkbage]

Sorry, what I'm saying is that with the new strategy React doesn't even know if something did mismatch or not because we don't actively patch up everything. Not everything is compared.

In general, I'm curious how other apps handle this production?

For React 16, there's not a lot of that use it in production yet. You're an early adopter. :) I think most don't handle it in production and just rely on this showing up at some point during development. A lot of this needs systemic handling by building frameworks around it that ensures that common patterns don't cause this.

[gaearon]

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.

[redonkulus]

@gaearon this would only work in development since the console.error messages are not displayed in production builds of React.

@lingyan opened an issue last summer requesting the ability to do this in production but was subsequently closed before the React 16 release.

I believe this feature is still warranted given the scenarios I mentioned in the original description. Correct me if I am wrong, but given fiber knows when the markup is not reused, would it be too much additional work to either add an attribute to the markup (data-markup-reused='false') or provide a hook (either via console.error or some other ability) for apps to listen to?