Virtualize emoji list

[onlyahost]

I know there was some discussion about this here and I am new to the repository. I hope I don't open an issue which was discussed before but the Github search didn't give me any results regarding this, so I will give it a shot.

Our case We are using the picker in an animated dropdown (CSS transitions of opacity and transform when mounting the dropdown). In cases like that the browser is animating and trying to render the whole emoji list at once which causes quite some lag. Lazy loading is taking some load off loading the images but it still needs to render the whole DOM tree.

Possible solution I think it would be fairly beneficial to virtualise the emoji list. Instead of using a library I think it would be enough to place a shared Intersection Observer on the Emojis (as they all have the same height it's not that much logic to write). If you didn't try that yet or have any strong opinion against it I might do an implementation and do a PR?

[ealush]

Hey @onlyahost, I personally do not have anything in particular against virtualization, and what was right for v3 (when my previous comment was made) may not be right for v4, since I wrote the picker completely from scratch recently.

I would love to see the picker's performance being improved using any means-virtualization included. I didn't give virtualization much thought in recent version, but here's what I think may require some creative thinking:

• Emojis are not a list, but a grid. Not all rows are full.
• Category titles take up space too, and they are not necessarily the same height as the emojis.
• When an emoji fails to render (due to network error or missing image in the cdn), the picker removes it from the render. This needs to be accounted for.
• Keyboard navigation calculation relies heavily on the emoji-count, divided by the amount of emojis in a row, and the current emoji index. We need to make sure that these calculations are not affected or that we have a good substitution for them.
• Keyboard navigation may lead to an emoji that's not yet visible (row below the viewport), we need to account for that as well.

I'd say, have a stab at it. I am willing to offer my help if this does indeed seem like something that's plausible.

[phuctm97]

I'd love to upvote this as well, I have the same use case as @onlyahost and it is consistently causing noticeable lag even on a Macbook Pro M1. Native virtualization would be improve the experience a lot.

[manuthecoder]

+1

I am also experiencing a noticeable lag on my Windows PC, not to mention my chromebook and phone.

[chavda-bhavik]

+1

[chavda-bhavik]

@ealush I would like to work on it, to hit the performance. Do you have any library preferences for it?

[ealush]

Sure, @chavda-bhavik, go ahead. In terms of library, I'll only allow a native solution.

Most virtualization library are not suitable for this specific need, and I've if they do, they bring with them other features that we're not interested in.

Instead, let's try to come up with something that would want without adding any dependencies