Make `customEmojis` reactive

[guanzo]

Is your feature request related to a problem? Please describe.
I want to be able to add emojis dynamically to an existing <VEmojiPicker>. However, the lib only checks for customEmojis in created(), then never again.

Describe the solution you'd like
React to changes to the customEmojis prop, and have the component display the new emojis.

Describe alternatives you've considered

1. Reaching into the component and mutating the data myself :/
2. Destroying and recreating component with new customEmojis, when my app finishes fetching the custom emoji data.

I noticed that customCategories is already reactive, since it's being used in the categoriesFiltered computed property, which is great. 👍

Thanks

[joaoeudes7]

Good! I will solve this, thank you!

[guanzo]

Sorry to keep pinging you with issues, but I noticed that your localStorage logic (for persisting "Frequently" used emojis), relies on array indexes. If my customEmojis is dynamic, then relying on indexes to restore emojis is obviously not going to work.

[joaoeudes7]

Yes, I noticed that too, I am trying to solve this problem and I will soon be launching a good update: D

[guanzo]

Hey.. another issue 😩 . These stupid browsers: Brave & Safari, throw errors when localStorage is accessed in a nested, 3rd party iframe.

I wrote a localStorage wrapper for myself, which works for my use case. https://gist.github.com/guanzo/571a0026ba90454fa9a6fde77f7701b6

But your lib also uses localStorage, and my error reporting service is going crazy.

I'm wondering if you could somehow allow users of this component to override usage of window.localStorage, with a custom storage API. To make it easy for everyone, you could mandate that this custom storage API implements this standard interface, https://developer.mozilla.org/en-US/docs/Web/API/Storage.

Thanks, I'm still loving this library 😁

[guanzo]

Another easier solution to my above problem, is simply add a frequentEmojis prop. Treat the prop as the source of truth for frequent emojis, and don't run the lib's default behavior for frequent emojis.

[joaoeudes7]

Hi, sorry for the delay, I had already implemented a solution, available in version 2.1.8, had forgotten to publish, thanks :)

[joaoeudes7]

@guanzo Did you resolve your update issue?

[guanzo]

customEmojis is now reactive, so that solves my original issue, ty.

The issues i'm facing now are:

1. You're still saving emoji indexes in localStorage, to restore "Frequently" emojis. What happens if customEmojis changes at runtime?

Let's say I load the component with 100 emojis. Then later, I remove 17 emojis, and add 23 emojis. The
stored indexes just became useless, because they now refer to the wrong emoji, therefore the
"Frequently" feature will show the wrong emojis...

2. Accessing localStorage in 3rd party iframe in Brave & Safari, throws an error. My sentry is blowing up with 150k+ errors, I need to handle this, preferably by not ignoring the error.

I'm also beginning to need more features:

• scoped slots for the main UI elements (emoji, scrolling container, search input, maybe a few others)
• pagination support (fire a custom event when user scrolls near bottom)
• virtual scrolling (this may not be necessary, with the recent <img loading="lazy"/> feature

I'm loading in thousands of new emojis at runtime, for each individual user. I need better performance, UI and network wise, b/c loading thousands of images into the DOM is not ideal. To clarify, i'm more worried about 1000s of network requests, rather than 1000s of DOM nodes, which is where loading="lazy", or pagination support, comes in handy.

These features may be out of scope for this lib, and my use case of running in a Twitch.tv extension is unusual, so rather than continue to bother you, I'm considering forking the repo and implementing these features myself.

[joaoeudes7]

1. Yes, saving the emoji index from the root emojis is a mistake, we really need to fix it.
2. I will check this problem on brave, but here (firefox, chrome) it doesn't happen.

• Scopes will be necessary, I am providing this at the moment
• Events on the Scroll? How much do you think is necessary?
• I imagine that the "loading" property will not work in this case since we are dealing with Unicode icons and not images, which also does not avoid creating elements in the DOM, so Virtual Scroll is really necessary, you cannot replace it with "lazy"

Feel free to contribute, I will be happy to receive your contributions :)

[guanzo]

No errors on chrome and FF, just stupid Brave & Safari. So annoying. You can see the error on my twitch channel. Just load the page with Brave and open the console.

Uncaught (in promise) DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.

• Regarding scopes, 👍

• To be honest i'm not sure if this lib should support pagination or not, but it's something I need.

If you want to add pagination support, i'd look at other pagination libs for inspiration. I am NOT advocating that you start sending http requests with offset and limit query params, like some pagination libs might do. All i need is an event that lets me know, "I need to fetch another page of data". So perhaps, just a single event, that fires everytime the user scrolls to/near the bottom.

• I forgot to mention, i'm replacing all the default emojis, with twemojis. And i'm loading in BTTV Emotes. These are all images, not unicode characters. This is why a lot of my issues are related to reactivity, because i'm replacing the default data! As I said, my use case is rather unusual 😁

I totally forgot about PR's, and jumped straight to forking haha. Will definitely contribute if I can. I'll have to learn typescript. From browsing your source, ts looks really elegant and easy to use!