SSR error with <Menu.Button>: Prop id did not match.

[ShaunDychko]

What package within Headless UI are you using?

@headlessui/react

What version of that package are you using?

v1.7.3

What browser are you using?

Chrome

Reproduction URL

https://github.com/ShaunDychko/headlessui-reproduce-menu-button-error

To reproduce

1. clone the repo
2. npm run develop
3. visit http://localhost:8000
4. inspect the browser console.

Describe your issue

The console logs the error:

Warning: Prop `id` did not match. Server: "headlessui-menu-button-:Rkp:" Client: "headlessui-menu-button-:R2j5:"
    at button
    at eval (webpack-internal:///./node_modules/@headlessui/react/dist/components/menu/menu.js:23:3867)
    at C (webpack-internal:///./node_modules/@headlessui/react/dist/internal/open-closed.js:8:255)
    at eval (webpack-internal:///./node_modules/@headlessui/react/dist/components/menu/menu.js:23:2487)
    at MyDropdown

This occurs when Gatsby's DEV_SSR flag is enabled in gatsby-config.js, which causes server side rendering when the page is refreshed. It occurs with react@^18, but not with react@^17. It's probably related to https://github.com/tailwindlabs/headlessui/blob/main/packages/%40headlessui-react/src/hooks/use-id.ts

I believe this causes React to re-render the page, which is consequential since it clears the cache from RTK Query and causes dynamic UI elements to flash between states while they're waiting for server data.

[RobinMalfait]

Hey! Thank you for your bug report!
Much appreciated! 🙏

When you are using React 18, then we are using the native useId hook exposed by React. I believe that this is a Gatsby bug with React 18 or it is part of your setup somehow (I'm not too familiar with Gatsby itself).

For example, if you replace the MyDropdown component with:

function MyComponent() {
  let id = `my-id-${React.useId()}`
  return <div>{id}</div>
}

// ...

<MyComponent />

Just doing this without any Headless UI at all will run into the same issue:

Which means that I'm afraid that there is nothing we can do in Headless UI to solve this, since we do want to keep using the native useId hook whenever possible.

[rijk]

This happens in Next.js too (v13.0.3, React v18.2.0).

[bitofbreeze]

same in Remix

[dmexs]

It looks like this was fixed in react here: facebook/react#25713

It doesn't look like there are any major react releases following this fix. Can anybody give guidance on how to work around this using canary or other releases of react?

[bitofbreeze]

Nice find @dmexs Looks like you can do something like npm update react@canary react-dom@canary per https://react.dev/blog/2023/05/03/react-canaries and https://react.dev/community/versioning-policy#canary-channel