Custom cache provider

[huozhi]

Changes

This PR is a early phase implementation for #728 . Add cache property as a cache provider to SWR context

import { createCache } from 'swr'

const customCache = new Map()
const { cache } = createCache(customCache)

<SWRConfig value={{ cache }}>
   <Section />
<SWRConfig>

This is the early support of #16 , user can have a way to access the cache state and changes ( #630 ), but won't effect swr internal cache. For example, you can use any store like localStorage / RN AsyncStorage, swr internal will still use a sync cache to guarantee the correct state updating sequence.

In the long term, we can consider to deprecate the exposed cache

Example

import { createCache } from 'swr'

const localStorageCache = {
   set(key, value) {
      window.localStorage.setItem(key, JSON.stringify(value))
   },
   delete(key) {
    window.localStorage.removeItem(key)
  },
}

const { cache } = createCache(localStorageCache)

return <SWRConfig value={{ cache }}>

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit e8c21fa:

Sandbox	Source
SWR-Basic	Configuration
SWR-States	Configuration
SWR-Infinite	Configuration
SWR-SSR	Configuration

[bionicles]

Might it be better to use the Cache API? it persists the data to apps installed locally on mobile devices, and it works inside WebWorkers https://developer.mozilla.org/en-US/docs/Web/API/Cache

https://caniuse.com/?search=cache

also, what about customizing the "get" in addition to the "set" ?

usage examples in readme would be helpful to adopt this

[shuding]

Generally LGTM! 👍

Since this is breaking and deprecates Cache, we need to first prepare a PR to add @deprecates to Cache for 0.x versions.

Secondly since we don't need to expose Cache anymore, I think we shouldn't wrap the provider with a class. We can just use a couple of lightweight functions:

function get(provider, key) { return provider.get(key) }
function set(provider, key, value) { return provider.set(key, value) }

And we don't need those internal listeners too. This change will be useful when we pass the provider down via context, and we don't maintain the cache singleton itself inside SWR.

[huozhi]

5834b59 latest change:

limit cache API usage inside swr, only using set/get/delete, and they're all sync APIs.

for global mutate and trigger, use const cache = globalCache to consume global cache directly;
for useSWR hook, it will consume provider from context or fallback to global cache.

[shuding]

I refactored the API a little bit:

const { cache, mutate } = createCache(provider)

But the implementation is still not ideal:

• The interface of provider. Should we do serialization inside or assume it's always a string?
• The internal code structure. use-swr depends on use-args, use-args depends on the default config and cache, but the default cache depends on use-swr. So I had to choose a strange way to implement this (defaultCache = getCacheFactory(() => {})(new Map()).cache).

I need to spend some more time thinking about it. I also moved web presets out of the default config object, because these can not be options. But I'm not very sure about that decision, let me know what you think!

[shuding]

While the main goal of this PR is to better cover testing scenarios, there're still a couple of to-dos left (no blocking this PR to be merged, just writing them down):

• Add a test case for multi-level cache + mutation
• Add a test case for multi-cache isolation (2 components with different cache provider)
• Need to make sure that cache doesn't change. Maybe by adding a useEffect to show a warning inside useArgs...? This needs to be done when we have dev/prod separated builds, so prod can strip many unnecessary things out such as useDebugValue.

[huozhi]

@shuding new changes genterally LGTM! you might also want to fix those lint warnings.

[shuding]

🎉🎉🎉