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

is there support for indexeddb? #273

Open
KiwiChris-xx opened this issue Mar 8, 2022 · 9 comments
Open

is there support for indexeddb? #273

KiwiChris-xx opened this issue Mar 8, 2022 · 9 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@KiwiChris-xx
Copy link

for our needs the size of local storage is not sufficient, the goal is to load from cache on subsequent visits

I know indexeddb is an old solution but I am not aware of another solution that can replace it.

@darrenjennings
Copy link
Contributor

Yea we could add a new cache adapter re: src/cache/adapters/localStorage.ts

@darrenjennings darrenjennings added help wanted Extra attention is needed enhancement New feature or request labels Mar 19, 2022
@ZeroThe2nd
Copy link

ZeroThe2nd commented Aug 9, 2022

I tried making one using idb-key-value, but the inherent issue is that the Cache adapter methods cannot be async, while IndexedDB's API is. So this would also require a change to the Caching base class and implementation.

@CavalcanteLeo
Copy link

CavalcanteLeo commented Aug 23, 2022

even with localforage?

@ZeroThe2nd
Copy link

@CavalcanteLeo As long as a library/anything requires async operations, it currently cannot be done as the cache adapter's methods don't allow async methods. That includes LocalForage, as per their own documentation:

image

.then indicates a promise, which we cannot use.

The entire IndexedDB API (the low-level browser type) is a promise-based API. As long as the Cache adapters can't work with get (k: string): ICacheItem<CacheData> | Promise<ICacheItem<CacheData>>, making it accept a promise or a normal return type, IDB can't be done properly. So this would require a library-side change.

As my current schedule is a bit tight, I can't promise (pun intended) I'll have time shortly, but I could try looking into making a PR to resolve the issue.

The only alternative for a short-term fix is use some workaround to de-promise-ify the library calls. That would mean using some wrapper function that waits until the promise is resolved before continuing, but this will definitely hurt performance, which is what you don't want.

@ZeroThe2nd
Copy link

@darrenjennings Are there any plans to make the cache adapters optionally support promises, or is this something that's not planned?

@edson-pro
Copy link

May be we can add in dexie db.

@ZeroThe2nd
Copy link

@edson-pro That would retain the same issue. Dexie relies on Indexed DB, so you'd need to un-async the asynchronous API from Indexed DB itself. This would require a change in the library to accept async (promise) type functions for its cache adapter. Which, seemingly, we're not getting. As this issue is still open without any response from the devs 😞

@edson-pro
Copy link

yeah, I get it @ZeroThe2nd, Thanks for the response.

@adamdehaven
Copy link
Member

Hey, sorry everyone I just saw this thread.
If anyone is open to contributing, I'm happy to help review any suggested changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

6 participants