feat(nuxt)!: use payload cache for initial data fetching by default

[pi0]

🔗 Linked issue

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Both useFetch and useAsyncData avoid fetching twice at the same time when a promise is running but skip any value in payload cache for initial refrash. A simple way to reproduce behavior:

<script setup lang="ts">
await useFetch('http://icanhazip.com', { key: 'test' })
await useFetch('http://icanhazip.com', { key: 'test', server: false })
</script>

The script above, causes another client-side fetching on initialization, despite the fact that we already have the same key in payload cache. There are other situations where this happens as well, including fetching in multiple components when a race-condition can happen for fast fetches.

This PR changes the default behavior to use payload cache for initial fetch when exists. Running the above example, will not cause another client-side request anymore. To avoid this new behavior, a new { initialCache: false } options can be provide (* see notes).

Any subsequent call of refrash either automated with watchers or manually triggered by user, will still cause fetching and updating payload cache.

Slightly breaking changes:

• refresh(_force) option is dropped. It wasn't making sense to have it and it was limiting future compatibility with refresh options. It should be either refresh() or refresh({}) (there are no public options yet)
• A code relying on the buggy behavior with double fetch might be broken. { initialCache: false } can be used as a workaround.

---

(*) useFetch's cache option can be either a Request Cache strategy or boolean. Value will be mapped to boolean for internal useAsyncData options.

In the future, we can extend cache option with different new strategies. Ideally consistent with Request Cache API.

Update: Using explicit initialCache for time being to avoid possibly usage conflict in the future development of cache support. (d6436a1)

[netlify]

✅ Deploy Preview for nuxt3-docs canceled.

Name	Link
🔨 Latest commit	85393de
🔍 Latest deploy log	https://app.netlify.com/sites/nuxt3-docs/deploys/62457c4d0a75d80008962a3d

[toooni]

@pi0 I am not sure if this is working properly. If I do have a page which fetches some data. The data is submitted from the server on the first request and the client by default does not make a "new" request to refresh the data. But as I see it the client also doesn't fetch new data if the same function is called again by f.e. a client route change. Is this intentional? How do I cache the first request (payload from the server) but avoid caching from there on when the same function is called on client side.

[StefanCardnell]

@pi0 @danielroe Similar to @toooni. I am using useAsyncData to fetch some data from an external API. However, I am noticing that all of my initial API request payloads are cached. I am working on an app where users need to see the latest version of the data, never cached. If they leave a page and come back, and that page obtains its initial data via useAsyncData, they will get a cached version. Am I expected to place { initialCache: false } on every API call - which in the case of my app, is basically all of them (I imagine for a lot of people and a lot of websites also?) - was this the intended behaviour with this ticket?

Having cached data returned is not obvious thing to spot and can lead to subtle bugs. Should cached API payloads not be opt in?

(This is a client-side only app - ssr: false).

[pi0]

I understand your concern about global behavior. It is tricky because sometimes, we also do not expect asyncData result is being changed to keep it in memory and it makes double calls. Hard to judge what fits for everyone. But you are right.

I'm going to work on an improvement soon about shared state. We could make it better to respect cache status specially with useFetch.