Implement workaround for hydration error on React strict mode

[ciffelia]

This commit implements a workaround for hydration error during SSR running in strict mode (#2231, #779).
The workaround uses React.useId, which is introduced in React 18. On React 16 and 17, nothing changes with this commit (i.e. hydration error still occurs).

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

yarn test:ssr

Note: I'm not sure if this test runs in react strict mode.

🧢 Your Project:

pixiv/charcoal

[snowystinger]

Thanks so much for starting this!

[ciffelia]

I'll update react-spectrum/ssr.mdx as well.

[devongovett]

Any idea why the original implementation doesn't work in strict mode? Is the useMemo being called multiple times? Should we use a ref instead?

Switching to React.useId is a big change and possibly orthogonal to the original issue. Plus, it only fixes it for React 18. Would be good to see if we can fix the original implementation, and move to React.useId as a separate improvement.

[ciffelia]

Yes, functions passed to useMemo are called twice in strict mode. This is done intentionally to detect side-effects of the functions: https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects

I don't think it is possible to generate consistent and unique IDs in hooks without having side-effects nor depending on React.useId. I looked into how other libraries work around this problem, and found out that they generates IDs client-side only if React.useId is unavailable.

• MUI: https://github.com/mui/material-ui/blob/27f9a61821a3d4d76ca0a085f9c779356ccd7753/packages/mui-utils/src/useId.ts
• ariakit: https://github.com/ariakit/ariakit/blob/8c22affaa76ecc07380ecf3cf36553121fe2dd40/packages/ariakit-react-utils/src/hooks.ts#L154-L170
• Floating UI (Popper): https://github.com/floating-ui/floating-ui/blob/f26129e16a3199413c3a1f49ed76227d5cf9c618/packages/react-dom-interactions/src/hooks/useId.ts
• Mantine: https://github.com/mantinedev/mantine/blob/97d7b75d501b596012fde7b212cd7e1bea16e8e7/src/mantine-hooks/src/use-id/use-id.ts
• Radix UI: https://github.com/radix-ui/primitives/blob/626ff92e52d35f4438fe58265f2c85116009072b/packages/react/id/src/id.tsx

[devongovett]

Maybe possible with a ref. Something like this?

function useId() {
  // ...
  let ref = useRef(null);
  if (ref.current == null) {
    ref.current = "react-aria-" + ctx.current++ // ...
  }
  return ref.current
}

(Typed on mobile, sorry for any mistakes)

[ciffelia]

I see. I think that idea would work well on React 17, but would cause hydration errors in concurrent mode on React 18, where the client and the server may not render components in the same order.

[ciffelia]

I believe React.useId is the only way to generate IDs that doesn't cause hydration errors on React 18 (that's why React.useId is introduced).
We may rewrite useIdForLegacyReact using useRef for React 16 and 17, but I think that should be done in another pull request.

@devongovett do you have any ideas?

[devongovett]

I believe that is only a problem when using the brand new streaming server renderer, which is only for Server Components not traditional SSR. Also we still support React 16 and 17, so we should fix the issue there as well. I think the approach I posted above might work for 16, 17, and regular SSR in 18. We would need to switch to React.useId for Server Components support at some point, but I'm concerned that there will be side effects from such a change. React Aria's useId is pretty deeply embedded in our libraries and lots of things rely on how it works, so we will need to be extremely careful about changing it. I would prefer to start with fixing the initial issue with strict mode, and tackling Server Components separately.

[ciffelia]

Thanks for the explanation. That makes sense. May I use the approach you posted above to check if it works? I would create a new pull request if successful.

[devongovett]

Sure, that would be great thanks!

[ciffelia]

I just tried the useRef approach, and unfortunately it turned out that doesn't seem to work. During the first render (hydration), useRef returns different objects for each call of our useSSRSafeId hook. That is, ref.current is reset after the first call, where we increment ctx.current.

This behavior doesn't seem to be documented clearly, but is described in facebook/react#22872 and facebook/react#18003 (comment).

[devongovett]

Hmm, this pattern is shown in the docs here: https://reactjs.org/docs/hooks-faq.html#how-to-create-expensive-objects-lazily

[ciffelia]

Although the docs implies ref.current is initialized only once, the initialization seems to run twice in strict mode.

https://codesandbox.io/s/loving-swirles-zc254v?file=/src/index.js

import { useRef, StrictMode } from "react";
import { createRoot } from "react-dom/client";

const rootElement = document.getElementById("root");
const root = createRoot(rootElement);

root.render(
  <StrictMode>
    <App />
  </StrictMode>
);

let cnt = 0;
function App() {
  const ref = useRef(null);
  if (ref.current === null) {
    ref.current = `id-${cnt++}`;
  }

  console.log(ref.current);
  return ref.current;
}

[LucasUnplugged]

@ciffelia: is the issue that the server-side correctly generates just one ID, and the client-side generates two?

Maybe this is a "if you can't beat them, join them" situation: could modify the server-side to first generate a throw-away ID, then generate one that gets assigned?

I guess ideally we'd want to also check if strict mode is disable before generating the first ID, if that's possible in the server-side (I'm assuming it is).

[ciffelia]

@LucasUnplugged I don't think that's possible. The SSR server sends rendered HTML to a browser immediately after the first rendering completed. There's no way to generate IDs after the first render.

[LucasUnplugged]

@LucasUnplugged I don't think that's possible. The SSR server sends rendered HTML to a browser immediately after the first rendering completed. There's no way to generate IDs after the first render.

What I mean is, it sounds like the frontend runs the ID generation code twice, so the first instance has ID 2 in the frontend and ID 1 in SSR code. The second has ID 4 instead of ID 2, and so on.

So in that case, I'm suggesting the ID generation func be run twice in the SSR logic as well, like:

genID(); // Throw away
const actualID = genID; // Save this one

If I understood correctly, the mismatch in IDs is deterministic, in that the first ID is always the same; the second is always the same; etc. The only difference is the frontend is doubling them up, in strict mode.

[ciffelia]

@LucasUnplugged I was mistaken about the behavior of Strict Mode. Indeed, I think the idea you presented is possible. Unfortunately it seems to be impossible to check if the strict mode is enabled (at least in the render phase), so we need to add an option to enable that feature:

<StrictMode>
  <SSRProvider strictMode={true}>
    <App />
  </SSRProvider>
</StrictMode>

Apart from that, I came up with an idea that allow users to let react-aria use React.useId internally:

import React from 'react'

<SSRProvider useId={React.useId}>
  <App />
</SSRProvider>

This will not only solve the problem with strict mode, but also ensure that our useId will work correctly with concurrent React.

Since both features are optional, there is less risk of breaking things. Those who are using React 18 may enable the latter feature, and others may choose the former. I would like to hear from maintainers before implementing them.

[brandonpittman]

Remix shipped their defer helper to allow streaming Promises and this is starting to become an issue now that the streaming stuff is being used.