Kong / swrv

Stale-while-revalidate data fetching for Vue

Home Page:https://docs-swrv.netlify.app

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Possibly unnecessary check

bart-jaskulski opened this issue · comments

Hi!

I wanted to delve on the decision of using useSWRV only as composable function. At the moment, you can use SWRV only in top-level setup function, as mentioned in this comment which was followed up by #133 to improve error message, stating that you actually should compose your functions in different way to use SWRV.

Yet… #304 pull request removed support for SSR cases with SWRV. The change is quite recent, as it's been about a month, yet for the time being we should expect that no support for SSR in coming at least until v2 (correct me, if I'm wrong).

Taking this under consideration, following lines are obsolete in keeping valid functionality.

swrv/src/use-swrv.ts

Lines 160 to 167 in 584d81c

const instance = getCurrentInstance() as any
const vm = instance?.proxy || instance // https://github.com/vuejs/composition-api/pull/520
if (!vm) {
console.error('Could not get current instance, check to make sure that `useSwrv` is declared in the top level of the setup function.')
return null
}
const IS_SERVER = vm?.$isServer || false

An only constant used through the file (from snippet above) is IS_SERVER, mostly deciding whether we want serverTTL either ttl from our config and revalidation (which would always be true in browser environment).

Minor edit of the package would enable a bit wider use case for swrv, possibly allowing it to run not only in component (or store) context.

for the time being we should expect that no support for SSR

This is correct. We're open to PR to add back SSR support. The APIs changed significantly in Vue 3, and the only real SSR use-case (Nuxt) has other ways of achieving the behavior.

Changing the behavior to allow just using the composable would disable some of the automatic "cleanup" that occurs in the onUnmounted hook, and would be a major breaking change.

The code block you mentioned is indeed no longer needed with the current setup but was temporarily left in place as we explore adding SSR support back to the package.