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.
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.