SWRV returns wrong cached data before first fetch while using key watcher function.

[peter50216]

CodeSandbox:
https://codesandbox.io/s/swrv-first-fetch-key-ip6ox?file=/src/App.vue
Click on the add button and see that check turns false.

I'd assume that the data returned by useSWRV is either undefined (no cache and data not yet available), or some cached data for that key (That is, check to be always true). Not some cached data for some older value of the key.

[darrenjennings]

your computed property is returning false when key.value !== data.value so the key is updated immediately, and the computed prop fires which then updates check to be false since the keys aren't the same, so it is not an "old" value. You could do something like this if you want "checked" to be true when the key has changed and a revalidation is occuring. https://codesandbox.io/s/swrv-208-i89pj

[peter50216]

The fetcher used is just an example, and might actually be some API calls instead. So it might not be that simple to actually know whether the data returned is some cached stall data for the correct key or not, without explicitly adding the key to the return value of all fetchers...
Also the corresponding code using React & swr library does the (imo correct) behavior:
https://codesandbox.io/s/falling-tree-mueb8?file=/src/App.js
That is, returning undefined for data when key changed and corresponding value is not cached and being fetched. (The check would always be true)

[darrenjennings]

@peter50216 you make a good point on the difference here, and are describing the behavior that we do not clear data to undefined when key changes. This is by design, though it is not consistent with swr. I don't use this library anymore so if the community wants to use the swr behavior, then we can align by setting data to undefined. It made my life hard when I implemented this, because swr users have to jump through hoops and use "useStickySwr" whereas swrv users the "sticky"ness is by default.

[peter50216]

I think it would be better to add an option for that since it would be a breaking change if we change the default, and from that linked react issue people sometimes do want the sticky behavior. I'll try to prepare a PR.

[pbowyer]

I don't use this library anymore so

Is this because you've replaced using it with another library, found it wasn't needed in practice, moved away from Vue or something else..?

I am about to start using it (or something similar) to deduplicate requests, so would be great to hear why before I start.

[darrenjennings]

Is this because you've replaced using it with another library, found it wasn't needed in practice, moved away from Vue or something else..?
I am about to start using it (or something similar) to deduplicate requests, so would be great to hear why before I start.

Hello @pbowyer! I had a vested interest in this library when I was employed at Kong, which included battle testing new features and guiding the api. I have a different job now but otherwise have no qualms with this library and would use it again if I build any vue apps! Happy to continue maintaining it until a community member steps up to do it.

[darrenjennings]

Closing from inactivity

[ivos]

I've also ran into this issue. I understand why would people want to use a "sticky" value. There are however cases when this is not desirable. I need to distinguish whether data does belong to the key or not and currently I am not aware of a way of finding this out.

Unlike SWR that supports both cases (even though the "sticky" case with an add-on hook), SWRV only supports one case - the "sticky" case, not the "data becomes undefined when not in cache yet" case. So instead of an add-on that could be kept outside of the library we need to add a new option to support this.

Are there any strong opinions on how this new option should be named? Does stickyResult : boolean with default true sound ok?

[ivos]

Alternatively, we can provide a new return value, a computed boolean named say isSticky that would be set iff the data does NOT correspond to the key.

This is functionally equivalent to the stickyResult option solution above. If required, one could easily compute non-sticky data like this:

const { data, isSticky } = useSWRV(...)
const nonStickyData = computed(() => isSticky.value ? undefined : data.value)

More often this would not be needed, one would just want to distinguish when the data does not correspond to the key (typically, to show a loading indicator).

I believe this design is better than the stickyResult option, because it does not introduce new variants (if statement) into the implementation and therefore leads to lower increase in the library's complexity.

@darrenjennings Before I spend time with a PR, what are your preferences re these two alternatives? Re the name of the return value / option? Any ideas?

[ivos]

Better yet, we could have a new return value named isLoading that would be true when there's a request ongoing and the data is either undefined or does not correspond to the current key.

That way users can show a spinner when either:

1. data is undefined, when showing cached data for the previous key is better than the spinner.
2. isLoading is true, when showing cached data for the previous key is undesirable.

[ivos]

Update: Just came accross https://swr.vercel.app/docs/advanced/understanding#return-previous-data-for-better-ux. SWR now has the config option and it is called keepPreviousData. Obviously,, it is false by default in SWR, but it could as well be true by default in SWRV.