Rendering all breakpoints on the server and then relying on hydration fixup to prune them is too expensive in 18

[gurkerl83]

We use a library called Fresnel to achieve the following

1. Render markup for all breakpoints on the server and send it down the wire.
2. The browser receives markup with proper media query styling and will immediately start rendering the expected visual result for whatever viewport width the browser is at.
3. When all JS has loaded and React starts the rehydration phase, we query the browser for what breakpoint it’s currently at and then limit the rendered components to the matching media queries. This prevents life-cycle methods from firing in hidden components and unused html being re-written to the DOM.

Latest compatible version: 18.0.0-rc.0-next-fa816be7f-20220128
First incompatible version: 18.0.0-rc.0-next-3a4462129-20220201
Most recent versions are still incompatible

Identified changes short after the last compatible version was published.

I did some digging into the recent changes in React and may have been able to identify the problem.

The initial report artsy/fresnel#260 (comment) describes an error thrown when server-side generated components no longer match those on the client-side. This change of application behavior was introduced in the following commit.

3f5ff16

In the same commit, further changes are made, with at least the following leading to another problem (assuming error throwing is disabled).

react/packages/react-reconciler/src/ReactFiberHydrationContext.old.js

Line 563 in 3f5ff16

} else {

if (nextInstance) {
  if (shouldClientRenderOnMismatch(fiber)) {
   warnIfUnhydratedTailNodes(fiber);
   throwOnHydrationMismatchIfConcurrentMode(fiber); // => (*2)
  }
  else { // => (*1)
   while (nextInstance) {
     deleteHydratableInstance(fiber, nextInstance);
     nextInstance = getNextHydratableSibling(nextInstance);
   }
  }
}

Local tests show that the condition statement "if/else" block is wrong; the delete operation must always be executed.

// *1 The delete operation of unmatched siblings needs to be called anyway; otherwise, DOM and React get out of sync, meaning phantom DOM entries (duplicated DOM Elements) get generated when re-rendering occurs. Those elements do not have a corresponding react component in the dev tools.

// *2 Throwing errors have to be optional, not mandatory, options to think about

Remove throwing errors altogether; at least make it optional because the third argument in hydrateRoot is not used/implemented by any consumer of this API, such as in NextJS, although they promise you can use the latest experimental React version
Disable enableClientRenderFallbackOnHydrationMismatch when suppressHydrationWarning is set.

Note: When looking at the associated hydration test suite https://github.com/facebook/react/blob/main/packages/react-dom/src/__tests__/ReactDOMServerPartialHydration-test.internal.js it is noticeable that in the tests mostly suspense is used. In the following test (no test exclusively output after hydration, first and second render run) simple elements are used.

it('with if / else in place', async () => {
  function App({hasA, hasB}) {
    return (
      <div>
        <div>{hasA ? <span>A</span> : null}</div>
        <div>{hasB ? <span>B</span> : null}</div>
      </div>
    );
  }

  const finalHTML = ReactDOMServer.renderToString(
    <App hasA={true} hasB={true} />, // Render markup for all breakpoints on the server and send it down the wire.
  );

  const container = document.createElement('div');
  container.innerHTML = finalHTML;

  const root = ReactDOM.hydrateRoot(
    container,
    <App hasA={true} hasB={false} />,
  );

  jest.runAllTimers();
  Scheduler.unstable_flushAll();

  /**
   * Results:
   * 1. current version if / else in place (wrong): => <div><div><span>A</span></div><div><span>B</span></div></div>
   * 2. only one if - delete on default (expected): <div><div><span>A</span></div><div></div></div>
   */
  console.log(
    'after hydration / hasA={true} hasB={false}:',
    container.innerHTML,
  );

  root.render(<App hasA={false} hasB={true} />);

  jest.runAllTimers();
  Scheduler.unstable_flushAll();

  /**
   * Results:
   * 1. current version if / else in place (wrong - phantom elements created): => <div><div></div><div><span>B</span><span>B</span></div></div>
   * 2. only one if - delete on default (expected): <div><div></div><div><span>B</span></div></div>
   */
  console.log(
    'first re-render / hasA={false} hasB={true}:',
    container.innerHTML,
  );

  root.render(<App hasA={true} hasB={false} />);

  jest.runAllTimers();
  Scheduler.unstable_flushAll();

  /**
   * Results:
   * 1. current version if / else in place (wrong): <div><div><span>A</span></div><div><span>B</span></div></div>
   * 2. only one if - delete on default (expected): <div><div><span>A</span></div><div></div></div>
   */
  console.log(
    'second re-render / hasA={true} hasB={false}:',
    container.innerHTML,
  );
});

Maybe you guys can give some feedback if the identified problem in those changes made is really the cause to the problem.

Thx!

[eps1lon]

How does this approach work in React 17? If it creates hydration warnings in React 17 then it's expected to also cause problems in React 18.

including wild error throwings, out of sync DOM nodes

Could you specify which errors are thrown?

Ideally you could create a repro by forking https://codesandbox.io/s/kind-sammet-j56ro

[salazarm]

// *1 The delete operation of unmatched siblings needs to be called anyway; otherwise, DOM and React get out of sync, meaning phantom DOM entries (duplicated DOM Elements) get generated when re-rendering occurs. Those elements do not have a corresponding react component in the dev tools.

The delete operation doesn't need to be called here because we end up calling clearContainer after setting Snapshot flag on the fiber

// *2 Throwing errors have to be optional, not mandatory, options to think about

Remove throwing errors altogether; at least make it optional because the third argument in hydrateRoot is not used/implemented by any consumer of this API, such as in NextJS, although they promise you can use the latest experimental React version Disable enableClientRenderFallbackOnHydrationMismatch when suppressHydrationWarning is set.

That error is thrown as an internal control mechanism. It's caught here . Only a legitimate error would bubble up.

Note: When looking at the associated hydration test suite https://github.com/facebook/react/blob/main/packages/react-dom/src/__tests__/ReactDOMServerPartialHydration-test.internal.js it is noticeable that in the tests mostly suspense is used. In the following test (no test exclusively output after hydration, first and second render run) simple elements are used.

it('with if / else in place', async () => {
  function App({hasA, hasB}) {
    return (
      <div>
        <div>{hasA ? <span>A</span> : null}</div>
        <div>{hasB ? <span>B</span> : null}</div>
      </div>
    );
  }

  const finalHTML = ReactDOMServer.renderToString(
    <App hasA={true} hasB={true} />, // Render markup for all breakpoints on the server and send it down the wire.
  );

  const container = document.createElement('div');
  container.innerHTML = finalHTML;

  const root = ReactDOM.hydrateRoot(
    container,
    <App hasA={true} hasB={false} />,
  );

  jest.runAllTimers();
  Scheduler.unstable_flushAll();

  /**
   * Results:
   * 1. current version if / else in place (wrong): => <div><div><span>A</span></div><div><span>B</span></div></div>
   * 2. only one if - delete on default (expected): <div><div><span>A</span></div><div></div></div>
   */
  console.log(
    'after hydration / hasA={true} hasB={false}:',
    container.innerHTML,
  );

  root.render(<App hasA={false} hasB={true} />);

  jest.runAllTimers();
  Scheduler.unstable_flushAll();

  /**
   * Results:
   * 1. current version if / else in place (wrong - phantom elements created): => <div><div></div><div><span>B</span><span>B</span></div></div>
   * 2. only one if - delete on default (expected): <div><div></div><div><span>B</span></div></div>
   */
  console.log(
    'first re-render / hasA={false} hasB={true}:',
    container.innerHTML,
  );

  root.render(<App hasA={true} hasB={false} />);

  jest.runAllTimers();
  Scheduler.unstable_flushAll();

  /**
   * Results:
   * 1. current version if / else in place (wrong): <div><div><span>A</span></div><div><span>B</span></div></div>
   * 2. only one if - delete on default (expected): <div><div><span>A</span></div><div></div></div>
   */
  console.log(
    'second re-render / hasA={true} hasB={false}:',
    container.innerHTML,
  );
});

I ran your test against the current version and got all the expected results.

[gurkerl83]

@salazarm
You are right; I got the results in the test when all throwOnHydrationMismatch calls were enabled again in the context file. It seems an error has to be thrown to get the intended results.

A few other questions remain. A Suspense boundary around the content is necessary to avoid bubbling the error up to the root where the app mounts, like in the test suite I mentioned, right?

Another question is towards an Error-Boundary. Do I need one, and where (at the root), you said it is handled internally, here looking a the function body the error seems to re-thrown here or do I mis-interpret this.

One last question is towards backward compatibility, using hydrateRoot without any option and, more specifically, "onRecoverableError." As mentioned above, in most cases, as an application developer, you rely on, e.g., on NextJs or similar, which call hydrateRoot here but for now, with any options specified. Does this new apparatus make it mandatory to specify the hydrateRoot option, or does it work without specifying?

Many thanks in advance!

[salazarm]

A few other questions remain. A Suspense boundary around the content is necessary to avoid bubbling the error up to the root where the app mounts, like in the test suite I mentioned, right?

Originally at the time of that commit yes, but that's because we were delaying the change to make it work without a boundary. Now it should work without a boundary, let me know if you see otherwise because that would be a bug.

Another question is towards an Error-Boundary. Do I need one, and where (at the root), you said it is handled internally, here looking a the function body the error seems to re-thrown here or do I mis-interpret this.

This error shouldn't be rethrown. Do you have a repro of that behavior?

One last question is towards backward compatibility, using hydrateRoot without any option and, more specifically, "onRecoverableError." As mentioned above, in most cases, as an application developer, you rely on, e.g., on NextJs or similar, which call hydrateRoot here but for now, with any options specified. Does this new apparatus make it mandatory to specify the hydrateRoot option, or does it work without specifying?

NextJS would need to add the option if you would like to handle the error with your own javascript (eg. for reporting through Sentry). But even without specifying the option you should the errors in your console.

Also, what is the exact issue you're facing?

[gurkerl83]

@salazarm Thanks for answering my questions, I will make a reproducer in the form of a minimal NextJs app.

[gurkerl83]

@salazarm I have created the reproducer, the sources are here https://github.com/gurkerl83/React-18-Hydration-Bug.git

The latest experimental version (a few hours old) of React gets used in the main branch.
There is also a branch that runs the app without errors on the last working experimental version 18.0.0-rc.0-next-fa816be7f-20220128 - about a month old).

The branch's name is With-Latest-Working-Experimental-Version.
It seems Vercel / NextJs I can not deploy a dev build; only production builds, it is not really helpful, so you have to build locally.

Steps to build and run

1. Clone the repo

2. Install dependencies (just run the command yarn in the folder)
yarn
3. Run development respectively production (either the first or the later for prod builds)
yarn dev
yarn start

4. Open Browser at http://localhost:3000

4. See the error thrown respectively the dev console

The link to the deployed version (build from main branch)
https://react-18-hydration-bug-with-latest-experimental-gurkerl83.vercel.app

Thx!

[salazarm]

Can you use codesandbox please. Also what is the expected behavior

[gurkerl83]

@salazarm I provided those information requested. I hope the wording is not too brash, I actually know little React internals just want to support here.

Here are the sandboxes:

Working version (from a secondary branch in the repo, with Reacts last working experimental version 18.0.0-rc.0-next-fa816be7f-20220128 - about a month old)
https://codesandbox.io/s/dawn-meadow-77t84i

Buggy version (from repos main branch, with Reacts latest experimental version, a few hours old)
https://codesandbox.io/s/sad-bell-16ucyf

Explanation of the app
You can see only 5 divs and their children, but in fact 10 divs are generated by the server and sent to the client, 5 for small screen widths, 5 for larger ones.

In the hydration phase, the children of such divs have to be removed, which do currently not fit; the parents remain in the DOM but are not displayed. Based on the current viewport, one or the other group gets selected.

The removal gets initiated by the client; only the client knows its actual viewport, see https://github.com/gurkerl83/React-18-Hydration-Bug/blob/a3046deca9a225345a3ee26b8cd05b99053d61eb/components/Segment.tsx#L54

When you open the working sandbox demo in a new window, also dev tools with the element inspector and resize the children respond.

Expected behavior

• Do not show the error messages from the buggy demo in the buggy version
• Client-side render fallback gets initiates differently now; see further down. Ensure the performance is even with the older implementation. I mention this here because I imagine invoking clear-container has to be part of some initialization phase here.

Exception throwing techniques to communicate deletion respectively initiate a client render fallback

Although using exception throwing techniques as discussed this afternoon will produce the desired results in testing, exceptions executed fast, one after the other, could cause a problem.

You mentioned the clear-container call gets executed after setting Snapshot in a fiber.

Logging when the clear-container call gets executed respectively, the container info surprised me; it is the entire DOM, not just the fragment container a sibling is part of and has to be removed from, thus invoking a client-side render on this container.

In terms of the demo, this would happen five times; for each mismatch determined, resetting in such a manner would not be very scalable and efficient; imagine removing possible hundreds of elements.

Hopefully, the intention is clear why we pre-render on the server side so many elements, which we then remove on the client again. If not, please look at Fresnel

The old implementation does this without even calling clear-container, I tried it, removed all throws again, and the clear-container function gets not invoked.

If you need more information, please let me know!

Thx!

[salazarm]

I took a look at the sandbox and this is the new expected behavior. We changed to this strategy for consistency reasons because there are edge cases with the old strategy where patching up the DOM would lead to wrong results. I recommend you make the initial render while hydrating return the same elements as the server and only hide the elements by changing attributes on the nodes.

[gurkerl83]

I recommend you make the initial render while hydrating return the same elements as the server and only hide the elements by changing attributes on the nodes.

This is not possible. It would be possible if relevant components differentiate in their styles only. When a swappable component set (mobile and desktop variant) differs in logic or in consuming different APIs, just "hiding" things means that the internals of both components gets executed all the time.

A mobile variant of a component fetches data from API A. The desktop variant fetches data from API A and B, "hiding" means that the fetch of API A gets executed twice, and the fetch fetches execution of API B one time.

Others effects from this strategy are that children of both component variants render all the time; this is also undoubtedly unnecessary overhead.

All these effects will happen on the initial render.
To avoid those problems, conditional render in the individual component variations is required.

See desktop and mobile.

I suspect many use cases will break when the current strategy goes into a stable release. Most important is a fallback towards what you call DOM patching.

The hydration strategy should respect situations where the server does not have all the necessary information in advance. Hydration and, more specifically, the first render of a component has to respect the information available by the client, which influences the output.

When hydration does not apply a fine-grained resolvent strategy at a container level, but on the mounting point, problems such as cumulative layout shift may not be preventable.

API wise, it would be nice to have an option on a container wrapping children similar to the property suppressHydrationWarning, but skipping the process of client render and fallback to the currently stable behavior.

It is just an early measure when conditional render gets executed based on the current media query. I think this has to be respected.

It would also be nice to learn about the edge cases and constellations the development team encountered in the past, which led to this kind of adjustment.

Thx!

[salazarm]

It would also be nice to learn about the edge cases and constellations the development team encountered in the past, which led to this kind of adjustment.

A concrete example that would help you understand the behavior is imagine you're rendering a grid of People and when you click on the person a chat tab to talk to them opens up:

The server sends:

<PersonA>
<PersonB>
<PersonC>

But on the client we end up rendering

<PersonA>
<PersonC>
<PersonB>

function Person({name, openChatTab, id}) {
   return <div onClick={() => openChatTab(id)}>{name}</div>
}

The hydration mismatch would occur on the text name. If we were to just patch this up then we when you click on Person B you'd actually end up talking to Person C. To render this correctly we would need to client render the whole list.