N
Nuxt•3mo ago
Jaden Drury

useFetch and keys that end up not being unique

Hey there everyone, I have a question about the key param on useFetch and how nuxt handles it not being truly unique. We have a component that is using useFetch to get it's data and the useFetch looks something roughly like this 
const { data: area } = await useFetch(
  `/api/areas/${areaId}`,
  {
    key: "areas",
    query: {
      ...
    },
  }
)
const { data: area } = await useFetch(
  `/api/areas/${areaId}`,
  {
    key: "areas",
    query: {
      ...
    },
  }
)
This component could be rendered multiple times on a page meaning we have several different instances where the areaId is different. But note that my key doesn't have the id in it to make it unique. What we've noticed is even though we've not given this a unique key there seems to be no issue with refreshing the data based on that key. If I call refreshNuxtData("areas") from a button on the same component it refreshes only the data from within that component. This doesn't make full sense to me though since all instances of the component are still sharing the same key "areas" since I didn't make it unique. It's doing what I want it do, refreshing only once particular instance of the data, but it feels unexpected since I failed to give it a truly unique key. Does Nuxt have some way of processing instances where a key that should be unique but actually isn't? That seems to be what is going on but I'd like to understand it more.
6 Replies
kapa.ai
kapa.ai•3mo ago
Hi @Jaden Drury. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the knowledge sources provided, I can offer some insights into your question about useFetch and keys that are not unique in Nuxt. You're correct that the behavior you're observing seems unexpected given that you're using the same key "areas" for multiple instances of the component. However, this behavior can be explained by how Nuxt handles useFetch calls internally. According to the Nuxt documentation on useFetch, if you provide a function or ref as the url parameter, or if you provide functions as arguments to the options parameter, then the useFetch call will not match other useFetch calls elsewhere in your codebase, even if the options seem to be identical. In your case, you're passing a dynamic areaId as part of the URL: 
const { data: area } = await useFetch(
  `/api/areas/${areaId}`,
  {
    key: "areas",
    query: {
      ...
    },
  }
)
const { data: area } = await useFetch(
  `/api/areas/${areaId}`,
  {
    key: "areas",
    query: {
      ...
    },
  }
)
Even though you've specified a key of "areas", Nuxt is likely generating a unique internal key based on the full URL, including the areaId. This is why each instance of the component is able to refresh its own data independently. However, it's important to note that relying on this behavior is not recommended. The Nuxt documentation states: "If you wish to force a match, you may provide your own key in options." To make your code more explicit and avoid potential issues in the future, it would be better to include the areaId in your key: 
const { data: area } = await useFetch(
  `/api/areas/${areaId}`,
  {
    key: `areas-${areaId}`,
    query: {
      ...
    },
  }
)
const { data: area } = await useFetch(
  `/api/areas/${areaId}`,
  {
    key: `areas-${areaId}`,
    query: {
      ...
    },
  }
)
This way, you're ensuring that each instance of the component has a truly unique key, which aligns with the expected behavior of useFetch and refreshNuxtData. As for your question about whether Nuxt has a way of processing instances where a key should be unique but isn't, the answer is yes, but it's not something you should rely on. Nuxt is doing some internal magic to differentiate these calls, but it's always better to provide unique keys explicitly for clarity and to avoid potential issues in more complex scenarios. Nuxt Documentation on useFetch ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
kapa.ai
kapa.ai•3mo ago
<@1176608708004958312> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
Jaden Drury
Jaden DruryOP•3mo ago
Okay yeah so based on that rephrasing of the documentation it seems to just be falling to the default behavior of using the passed url to make it unique rather than only depending on my provided key.
manniL
manniL•3mo ago
@Jaden Drury you could set the key to areas-${areaId} (if that isn't reactive)
manniL
manniL•3mo ago
also check https://github.com/nuxt/nuxt/issues/21532
GitHub
useFetch & useAsyncData reactive key · Issue #21532 · nuxt/nuxt
hi @pi0, @danielroe is it possible to pass the "key" on calling refresh/execute or making the key computed in options? In my case i got a computed header with Authorization and custom key...
Jaden Drury
Jaden DruryOP•3mo ago
Oh yeah I'm fully aware of how to fix it to do that. It was more I wanted to confirm why it was it was still seeming to work even though I had initially forgotten to add it. And how big of a deal it would be to try and fall back on that behavior if it was a pain to access the variable that was being keyed if I was trying to call a refresh from somewhere that didn't automatically have the key value I'd need on hand.

Did you find this page helpful?