useFetch lazy: true keeps result in cache when client side navigation – intended? How to prevent? about nuxt HOT 4 OPEN

Same applies to useAsyncData.
It looks like everything that is fetched with these composables is always stored in the NuxtData cache.
I guess there might be use cases when storing old value of data is desired, like showing progressbar on top of list results.

One way is to use v-else in template.

If it's important to ensure that the data is getting unset you could clear the cache manually.

const { data, status, clear } = await useFetch(
  "https://reqres.in/api/users/?delay=1",
  {
    lazy: true,
    server: false,
  },
);

onUnmounted(() => {
  clear();
});

When clearing data this way there is an edge case if you navigate to the same page, for example from /post/1 to /post/2. Calling clear on unmount would cancel the fetch for new page and status of query would be set to idle.
To make it work ensure that you pass unique key to useFetch.

const { data, status, clear } = await useFetch(
  "https://reqres.in/api/users/?delay=1",
  {
    key: `post-${route.params.id}`
    lazy: true,
    server: false,
  },
);

onUnmounted(() => {
  clear();
});

clearNuxtData composable also could be used for clearing the cache.

from nuxt.

I have the same issue but with the error property, it also gets cached this way.
Here is the reproduction link: https://stackblitz.com/edit/github-6epge4?file=pages%2Ffetch-page.vue

If navigate to Home and then back to Fetch page the old error is still available.
There are different workarounds for this but I find it not very comfortable in terms of error handling for lazy data-fetching.

For example we want to redirect to 404 on both - client and server - with useLazyFetch.
If we don't clear the nuxtData manually on unmount - we might have the following scenario:
1 - user visits /post/123invalid and gets 404 page
2 - on 404 page user clicks "Go to home page"
3 - from the Home page user navigates to /post/123
If error is not handled correctly - the user could be immediately redirected to error page because the old error is not null.

If we want to use the same handler for client and server - possible solution is:

const { error } = useLazyFetch('/api/get-something');

watch(
  error,
  () => {
    if (!error) {
      return;
    }

    if (error.statusCode === 404) {
      createError({ status: 404 });
    }
  },
  {
    immediate: process.server,
  }
);

In the above example it's important to set immediate flag on watcher only on server. So on client it wouldn't trigger during component setup.
But if we decide to change useFetch to be not lazy, then it is important that immediate option on watcher is always true. Or just not use watcher, check for error synchronously.

I guess it would be more predictable if error would always get unset when new api call is made, right before the fetch.
Or at least to have some option to configure whether we want to unset error/data right before the fetch or useAsyncData handler.
Or maybe have option to configurate automatic cleanup of NuxtData when this data is not used on the page.

from nuxt.

I guess it would be more predictable if error would always get unset when new api call is made, right before the fetch.

Didn't think about use cases involving error yet; sounds to me this suggestion makes a lot of sense. Thinking about it, I'm surprised even the error is cached in payload– surely there's a reason for this.

How about a payload: false option, which then only keeps data, error, status etc. locally?

from nuxt.

Same issue here when using useLazyFetch with watch immediate: true, and currently use onUnmounted clear() to solve it.

https://codesandbox.io/p/devbox/uselazyfetch-data-cache-5fnjq8

from nuxt.