[RFC] Configurable Cache

[huozhi]

Background

Currently swr cache (0.4.x by the time) is a kind of hidden functionality, which exposed one experimental cache but not really fully documented with guaranteed. swr will leverage cache to store the states of keys, and mutate API can also manipulate states and cache at the same time.

We received few issues/Q&A about how to manipulate the cache directly and make its value aligned with swr's state, which confuse users sometimes.

Goals

• Be able to store cache data elsewhere outside of swr, adaptive to different kinds of data presistence layer
• Be able to declare initial value for cache of swr context

Proposal

Add a new property cache to swr context and let user be able to customize their cache. Fiting one cache API contract, and could be able to switch the underlayer providers like localstorage, RN AsyncStorage, any global state, etc. Note: cache is not available for swr hook

type CacheProvider = {
   initialData?: any;
  set?: (key: string, value: any) => void;
}

const localStorageCacheProvider = {
  initialData: {},
  set(key, value) {
    window.localStorage.setItem('_swr_cache_' + key, JSON.stringify(value))
  }
}

<SWRConfig value={{cache: localStorageCacheProvider}}>

Discussion

This is just a draft or an idea, won't be happened immediantely or break the current swr usage. Any comments or suggestions please let us hear from you. Thanks

[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" ?

[shuding]

Thanks for putting this up!

Since the cache config (especially initialData) has to be a singleton, I'm proposing the following API changes, let's take Map as an example:

import { createCache, SWRConfig } from 'swr'

const __cache = new Map([['key', 'value']]) // no need to pass this as "initialData"

const { cache } = createCache<T>({
  set: (key: string, value: any): void => __cache.set(key, value)},
  get: (key: string): any => __cache.get(key),
})

function App () {
  return <SWRConfig value={{cache}}>...</SWRConfig>
}

This can help build the mental modal that the cache provider is a singleton. And the returned object can also contain more APIs in the future which is more flexible.

Generally I'm -1 on the idea of letting users manipulating the internal cache directly (the current impl.). It can easily mess up the application state if done wrong.