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

Extra rerender on hover item #2782

Closed
Miladxsar23 opened this issue Oct 2, 2023 · 2 comments
Closed

Extra rerender on hover item #2782

Miladxsar23 opened this issue Oct 2, 2023 · 2 comments
Assignees

Comments

@Miladxsar23
Copy link

What package within Headless UI are you using?

@headlessui/react

What version of that package are you using?

v1.7.16

What browser are you using?

Chrome, Safari, or N/A

Describe your issue

I have realized that for large data in the ListBox and Autocomplete components, additional renders occur on hover over items, which significantly impacts performance. This can be applied to each item individually because hover has no effect on the active and selected states.

@thecrypticace thecrypticace self-assigned this Oct 2, 2023
@thecrypticace
Copy link
Contributor

This happens as a result of <Listbox> being the source for which option is currently active. We do this because we have to figure out what the prev and/or next option to move to is based on arrow keys when you use them. This is inherently not an operation local to a single option. Since <Listbox>'s state is updated it's re-rendered which, in React, also re-renders all children.

There might be some useMemo-ish stuff we could do here but I'm not certain that's possible in this case.

@RobinMalfait Any thoughts here?

@RobinMalfait
Copy link
Member

Hey!

Even with useMemo, the Listbox.Options itself still needs to know the currently active option because the aria-activedescendant needs to be set to that value for assistive technology support.

The problem is unfortunately also way trickier than it looks. If you used the keyboard to go to Option A (or if it was pre-selected when opening the Listbox), if you then use your mouse (which can exist in a spot not even near the Listbox) to go to Option B, then Option A won't receive any events, so we won't be able to turn off the local active state for Option A. This would result in both Option A and Option B to be in the active state if we keep that state local.

I also wouldn't recommend to use a lot of options in the Listbox, because even if we make it very very fast, and solve all of the problems above, it's still not ideal to use as an end user with a lot of data (e.g.: you can't search to reduce the amount of options you see).

Instead, I would recommend to use the Combobox component, and use the new virtual mode to handle the performance bottlenecks.

You can use this new feature when using the insiders build, more info about the usage can be found here: #2779

Hope this helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants