Skip to content
This repository has been archived by the owner on Sep 26, 2023. It is now read-only.

Alternative emoji storage #199

Closed
hognevevle opened this issue May 18, 2022 · 3 comments
Closed

Alternative emoji storage #199

hognevevle opened this issue May 18, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@hognevevle
Copy link

Hi there!

Love the work you've put into this 馃檹

Because our app is being embedded on 3rd party sites using an iframe, IndexedDB is not always available, e.g. if the browser is in incognito/private mode. This, unfortunately, causes picmo to crash.

CleanShot 2022-05-18 at 14 53 53

CleanShot 2022-05-18 at 14 54 14

Any way to provide a fallback behaviour in the case when IndexedDB is not available?

@joeattardi
Copy link
Owner

Thanks for filing this! Unfortunately this seems to be a use case I overlooked. I guess I didn't realize that iframes didn't always support IndexedDB.

Unfortunately there isn't an alternative. There may be an IndexedDB polyfill available but I'm not sure? Either way, for such cases I think I can have a solution for this in a day or two.

For these cases we could just have an in memory data store. It's not super efficient and will require everything to be kept in memory. Since it won't stay cached there's little benefit to downloading from the CDN in that case since you'll have to redownload it each time.

I'm thinking maybe an additional package that bundles the emoji data from emojibase coupled with a very simple in memory store. I can add a new picker option for this data store, and if one is specified it won't attempt to use IndexedDB.

Maybe not the most ideal, not sure. What do you think?

@joeattardi joeattardi added the enhancement New feature or request label May 18, 2022
@hognevevle
Copy link
Author

hognevevle commented May 18, 2022

Many thanks for the feedback, and no worries; I do realize this is a bit of an edge case. I expect it to only affect a very small percentage of users, so I'm not too concerned about it perhaps being slightly suboptimal for them (after all, it would better than the alternative). I think therefore your proposal sounds good 馃檪

@joeattardi
Copy link
Owner

Fixed in 5.1.0!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants