Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NextJS Warning: Prop aria-describedby did not match. #842

Open
danielpaz6 opened this issue May 24, 2020 · 5 comments · Fixed by #1561
Open

NextJS Warning: Prop aria-describedby did not match. #842

danielpaz6 opened this issue May 24, 2020 · 5 comments · Fixed by #1561
Labels
bug help-wanted An issue that needs additional investigation or community feedback to resolve

Comments

@danielpaz6
Copy link

danielpaz6 commented May 24, 2020

Describe the bug
When using next.js and adding Tooltip component, it displays this error:

Warning: Prop aria-describedby did not match. Server: "evergreen-tooltip-192" Client: "evergreen-tooltip-1"

To Reproduce
Steps to reproduce the behavior:

  1. Open new NextJS project
  2. Install evergreen-ui
  3. Use <Tooltip /> component.

Evergreen Version
4.27.4

Environment (please complete the following information):

  • OS: windows
  • Browser chrome
@danielpaz6 danielpaz6 added the bug label May 24, 2020
@Chrischuck
Copy link
Contributor

Chrischuck commented Jun 1, 2020

This happens because of SSR.

Under the hood, evergreen will automatically generate the aria-describedby attribute. It'll be generated once on the server and once on the client and unfortunately this is pretty much the default behavior with any SSR app.

Unfortunately, it doesn't look like you can manually set this (which would alleviate the problem). See here. The aria-describedby is derived from this id, ideally, you'd be able to put an id onto the tooltip and override this.

I can make a pr to add an override prop if you are fine with passing this id explicitly to fix this issue

@jasonbarry
Copy link
Contributor

Semi-related, I'm seeing this error for some of my classNames – specifically, all the classes are present / match between server and client, but some are out of order:

Prop `className` did not match. 
Server: "... 📦f-wght_400 📦ln-ht_21px 📦ltr-spc_-0-05px 📦txt-algn_center ..." 
Client: "... 📦f-wght_400 📦ltr-spc_-0-05px 📦ln-ht_21px 📦txt-algn_center ..."

@polosson
Copy link

Hi!

In the same manner, the bug appears on the Combobox component.
It would be great to be able to override the id prop of those components (I mean Tooltip and Comboox), like we can do for the TextInput component, for example.

So I 👍 the @Chrischuck PR proposal 😃!

@ethanmick
Copy link

Just ran into this as well. Would it be okay to add an id prop instead of generating one?

@brandongregoryscott
Copy link
Contributor

Reopening this to serve as a placeholder for a system-wide useId implementation that works for SSR. Explicit IDs are OK, but it seems like we should fix the behavior for all components that generate ids using it.

@brandongregoryscott brandongregoryscott added the help-wanted An issue that needs additional investigation or community feedback to resolve label Jan 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug help-wanted An issue that needs additional investigation or community feedback to resolve
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants