`useFetch` does not account for params change

Environment

Nuxt CLI v3.0.0-rc.6 16:22:47 RootDir: * 16:22:47 Nuxt project info: 16:22:47

---

• Operating System: Darwin
• Node Version: v16.15.1
• Nuxt Version: 3.0.0-rc.6
• Package Manager: yarn@1.22.19
• Builder: vite
• User Config: modules, build, runtimeConfig
• Runtime Modules: @nuxtjs/tailwindcss@5.3.0
• Build Modules: -

---

Reproduction

https://stackblitz.com/edit/nuxt-starter-brbcqx?file=pages/index.vue

Describe the bug

When we use useFetch with the same URL, but with different query string parameters, changing the parameters does not trigger a new fetch. As you can see in the repo, navigating from Page One to Page Two, and back, does trigger the composable useData, but the data is not fetch given new params. If you navigate to / or /page2 directly, then we can see the correct data.

Additionally, using the querystring directly in the URL also results in the same bug.

Additional context

No response

Logs

No response

[jshimkoski]

I think the docs are wrong/need updating. I read in another discussion that the key is now generated by “static code location”, i.e., where the useFetch call actually lives in a file, as opposed to the “path” and “parameters”.

This is inherently flawed as this means if you are using a single source of truth for API calls (a single useFetch wrapper), your key will always be the same, thus, it will produce this issue and in some cases (as in my project), it will just blow everything up.

To fix this in my project, I set a unique key using the path and the parameters, and I set initialCache: false in the request properties.

Setting initialCache: false will prevent caching the first request for a key, so it’ll always give you up-to-date data.

The bummer about this though, is you lose caching, so all of your API calls can feel a little sluggish in comparison to having it set to true.

You might be able to get around that sluggishness if you use Apache or Nginx as a reverse proxy with caching in place. It all depends on your setup and requirements.

Long story short, I think the strategy for the way the unique key for requests is generated needs to be re-implemented with a more robust solution. It doesn’t act the way it should and developers shouldn’t have to dig this deeply into the way it works to have useFetch work the way it is expected to work.

[agracia-foticos]

Resolved! I use this code:

import { hash } from ‘ohash’

and send key with this code ‘key’ : hash([‘api-fetch’, url, params]),