-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[Bug]: Performance issues with Select Custom Dropdown on big lists #474
Comments
Same for @headlessui/vue. It takes ~ 5 seconds to open a popup with around 1000 items. Good solution would be to lazy load entries (like vuetify does), but i don't know if this is possible with "headless" |
Yes same for me, but I do also notice some jitters when scrolling (only when moving mouse over list items and triggering the active/selected states), I'm currently using it as a list of countries (249) |
I managed to virtualize the options by using https://github.com/bvaughn/react-window, but then the accessibility (pressing up and down arrows) gets messed up. |
Yeah currently all |
Yea this is a problem for us as well. It looks like all of the options are re-rendered when the user hovers over each option. |
Just experienced the same with a language drop-down of 150 values, getting unusable results on mobile. |
I thought it was an issue on my end, but looks like the component is just not well optimised. I need to render lists up to 1000 entries, which is unusable with this select |
Bumping this issue. Having a country list of 240 items makes it nearly unusable (Using the Vue version). |
Hey! Thank you for your bug report! Currently our components don't implement windowing / virtualisation so the performance issues are currently expected if you throw a lot of items at them. I took note of it to explore using Headless UI with tools like react-window as @ErickTamayo explored and once we have that figured out we will document it. |
I don't quite understand the reasoning behind closing this issue when this issue that is perceived as a bug by developers using headlessui is not remedied. Is there a public roadmap somewhere, where this issue could at least be linked so we can keep track of progress in any other way than subscribing to this issue? I don't mean to sound rude or anything. We are quite happy using headlessui and so far, have not run into any trouble other than lack of performance. We are quite happy that these formidable components are provided to use. |
On the React side at least, most of the slow-ness comes from This is about 2000 items, and takes approximatively 8 seconds on this Core i7 laptop. Digging a bit deeper, this function is indirectly used by I'm not an expert with algorithms but I'm pretty sure that @RobinMalfait I'm not familiar with what the code is trying to accomplish but it seems likely performance can be improved somehow before going down the windowing route? Edit: On my M1 Pro, loading 2000 items "only" takes two seconds but the bottleneck appears to be the same. I ran the playground and changed this line to this:
It does seem like it is exponentially slow: 3000 items takes... a long time and 4000 items causes Edge to hang. Of course this is not a viable solution but if I 👀 At least part of the the problem seems to have been introduced in this PR. So it seems like you were aware of the performance drawbacks. If windowing is indeed the only viable solution, would you accept a PR to do it internally or do you think it's best to do it in user-space? |
It took me a while to get it just right but windowing works quite well with Once I got everything set up, I was able to overcome most (all?) quirks by being somewhat generous with overscan. For a list of about 2000 items, 25 seems to do the trick. |
@Zertz could you share how you made the listbox work with |
Last time I tried something similar, keyboard navigation through items broke. I am also interested in your solution. Can you provide a minimal example? |
Started putting together an example in the react playground, I'll try to create a PR this evening! |
Just checking in @Zertz, were you still considering sharing a playground with a demo? I am really struggling to get react-virtual to work with the Listbox, would love to see what you did to combine them. |
I'm sorry, I got caught up in a million things. I'll try to finish the demo shortly. |
Hitting a similar issue, would like to know if any one knows how to improve the perf issue 🙏 |
@leoyli-headsup |
@aburtsev you can't use these together with the listbox component because of the problem I outlined above. |
@Zertz Don't mean to be a bother, but any chance you'll get around to that example anytime soon? Would be highly appreciated. |
here's a quick demo of using it with tanstack react-virtual. couple of notes
|
Anyone managed to make a workaround for Vue for this performance issue ? |
got the some issue with vue, isn't this supposed to be top priority to do? |
finally i fix this on vue, combining |
This issue should be reopened as it is not fixed for the Vue variant. |
It's also not "fixed" for React. As mentioned in my comment here: #474 (comment) currently we don't support it and you can use other tools to work together with Headless UI to implement windowing. It's not a bug, it's just a feature we didn't implement yet. |
What package within Headless UI are you using?
@headlessui/react
What version of that package are you using?
v1.1.1
What browser are you using?
Firefox
Reproduction repository
https://github.com/khuang7/headlessui-listbox-issue (yarn install then yarn start)
Describe your issue
I am trying to populate a pretty big list (500 elements) into the Simple Custom component found in TailwindUI for my project. The hover behavior when trying to select an option becomes quite slow when you try to move the mouse around on all the options. Also generating the list can sometimes be slow as well.
My workaround this problem is to replace Listbox.Options and Listbox.Option to ul and li html elements so that I can just call 'hover:' on the li elements which improves performance significantly. But I would prefer to keep using the HeadlessUI instead of HTML because I would lose a lot of the ARIA accessibility features.
I was wondering if there is a way to deal with the performance issues in the HeadlessUI. I could only pinpoint the issue being related to ListboxOptions and ListboxOption.
The text was updated successfully, but these errors were encountered: