Replies: 4 comments
-
I think you have to store the timestamp of cache write somehow. I wrap the data in new object and add a new timestamp property: https://github.com/piotr-cz/swr-idb-cache/blob/v1.0.0-rc.2/src/storage-handler/timestamp.ts |
Beta Was this translation helpful? Give feedback.
-
Very cool, thanks for the examples @piotr-cz! I'd still love it if the API were baked into |
Beta Was this translation helpful? Give feedback.
-
I'm exploring a solution to set a cookie that expires when I want the cache to expire. One possible downside is that it might be a little harder to test? Not really sure yet. This seems to be working, though probably not the cleanest (not much in the way of error checking, handling edge cases). Mostly going for brevity here to share the idea. import useSWR from 'swr'
import fetcher, { getUserPath } from 'api/getUser'
export const useAuthenticatedUser = () => {
const userStorageKey = 'someKey'
const maxAgeInSeconds = 60 * 60 // 1 hour cache TTL
const expireCookieKey = 'expireStore'
// if the expire cookie doesn't exist, set the path for SWR so it fetches
const path = document.cookie.indexOf(`${expireCookieKey}=`) === -1
? getUserPath
: null
// SWR will only fetch if the path is set (expire cookie isn't present)
const { data: user, isLoading } = useSWR(path, fetcher)
// if SWR fetched and we have user data
// set the new expire cookie and save the user data in localStorage
if (user) {
document.cookie = `${expireCookieKey}=1; max-age=${cacheLifetimeInSeconds}; path=/`
localStorage.setItem(userStorageKey, JSON.stringify(user))
}
// this is a little tricky here because you'll need to check if `isLoading` when using in views
const userFromStorage = localStorage.getItem(userStorageKey) || '{}'
return {
user: user || JSON.parse(userFromStorage),
isLoading,
}
} |
Beta Was this translation helpful? Give feedback.
-
Here's my use case where this would be really valuable. I'm building a UI for booking a doctors office appointment. Our API returns available appointment times, but while the user is on the scheduling page (or filling out other fields before booking their appointment) some appointment slots might be booked by other patients. I'd like to assume that availability data is valid for 1-2 minutes, but beyond that it must be assumed to be outdated and refetched. The user can click through multiple months, each triggering a new API request by changing the "current month" part of the SWR key. Only one month is rendered at a time. The call to fetch appointments is expensive, and there is no way to detect when other patients book an appointment, so we need to strike a balance between caching the data on the client and not caching it for too long. A cache TTL would perfectly fit our use case. |
Beta Was this translation helpful? Give feedback.
-
Feature request
This may be counter to the philosophy of this library, but I thought I'd check.
I'd like to cache my data for a specific amount of time in Local Storage, e.g. 24 hours, and only revalidate after that TTL expires.
I found the docs for Local Storage based cache.
I scoured the Options and it looks like I could turn off all the
revalidate***
options, but I'm not sure if there's a way to keep track of how old cached items are, and revalidate when expired. It'd be amazing if this was a built in feature.Beta Was this translation helpful? Give feedback.
All reactions