You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's possible to render a "predicted" target during SSR, but the guess might be incorrect.
In order to "fix" we have to render everything twice:
first with predicted target, to match SSRed markup
next with the real target, where some pieces of Application could be rendered a bit differently. And that has a cost.
Proposal
MediaMatches might partial hydrate their children, in order to keep existing HTML if targets do not match, and update with a proper markup later.
that would reduce the amount of work React has to do.
MediaServerRender can do it automatically for a whole application as well.
Should be safe due to a top-level matches provider, which can orchestrate everything below it.
Alternatively
expose "couldUseHydration" function, which will propose to use render in case of hydration will lead to a double rendering. It's way faster to drop HTML and render ReactComponent, than to hydrate twice.
The text was updated successfully, but these errors were encountered:
It's possible to render a "predicted" target during SSR, but the guess might be incorrect.
In order to "fix" we have to render everything twice:
Proposal
MediaMatches
might partial hydrate their children, in order to keep existing HTML if targets do not match, and update with a proper markup later.MediaServerRender
can do it automatically for a whole application as well.Should be safe due to a top-level matches provider, which can orchestrate everything below it.
Alternatively
render
in case ofhydration
will lead to adouble rendering
. It's way faster to drop HTML andrender
ReactComponent, than to hydrate twice.The text was updated successfully, but these errors were encountered: