feat: Add cache to IndexedDB

[chenzhaozheng]

Add cache to IndexedDB

https://github.com/Kong/swrv/issues/273

here is another use case that supports indexedDB.

• The storage capacity is much larger than that of local storage.
• Support complex data structures.
• asynchronous operation
• Index and query capabilities

import useSWRV from 'swrv'
import IndexedDBStoargeCache from 'swrv/dist/cache/adapters/indexedDBStoarge'

function useTodos () {
  const { data, error } = useSWRV('/todos', undefined, {
    cache: new IndexedDBStoargeCache(),
    shouldRetryOnError: false
  })

  return {
    data,
    error
  }
}

[netlify[bot]]

👷 Deploy request for docs-swrv pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	1e1f352e7df1d1d46ca793ceda957083b4a2cfa8

[CLAassistant]

All committers have signed the CLA.

[chenzhaozheng]

@adamdehaven Hello, could you please help me check this PR? Thank you

[Justineo]

Thank you for the contribution!

But I think we should align the design with SWR and avoid adding complex async logic at the cache read/write level. The reasoning behind this is explained in detail in this SWR issue: https://github.com/vercel/swr/issues/16.

[chenzhaozheng]

Thank you for the contribution!

But I think we should align the design with SWR and avoid adding complex async logic at the cache read/write level. The reasoning behind this is explained in detail in this SWR issue: vercel/swr#16.

Thank you for your answer. I saw this ISSUE https://github.com/Kong/swrv/issues/273 , so I hope to support this cache more. As for following SWR's single global cache to store all data https://swr.vercel.app/blog/swr-v1#custom-cache-provider ， https://swr.vercel.app/docs/advanced/cache As an improvement, you can also use the memory cache as a buffer and write to periodically. You can also implement a similar layered cache with IndexedDB or WebSQL.localStorage. I think it depends on how users use it and whether they can strengthen the logic of the previous implementation. Enable users to customize their use of this feature and accept the issues that this asynchronous approach may bring. I hope to be of help because I am also researching and studying this area.

[Justineo]

Thank you for the detailed thoughts and suggestions!

I agree that supporting more flexible caching strategies is valuable. However, I think we should be cautious about making the cache read/write API itself asynchronous.

That said, I do think it’s worth exploring ways to implement async behavior under the hood—such as using an in-memory buffer with periodic persistence—while still exposing a synchronous interface. This could strike a balance between flexibility and ease of use.

Appreciate your insights—this is definitely a space worth digging deeper into.

[chenzhaozheng]

Thank you for the detailed thoughts and suggestions!

I agree that supporting more flexible caching strategies is valuable. However, I think we should be cautious about making the cache read/write API itself asynchronous.

That said, I do think it’s worth exploring ways to implement async behavior under the hood—such as using an in-memory buffer with periodic persistence—while still exposing a synchronous interface. This could strike a balance between flexibility and ease of use.

Appreciate your insights—this is definitely a space worth digging deeper into.

Okay, take a look at my PR and see if it's helpful. I've thought about it because I also provided an adapter instead of changing the underlying logic. If there are any good ways in the future, we can discuss them together. Thank you