Can I reuse the same cache entry for different API requests, where one of them contain a subset of the other?

[jimmycallin]

I have an API similar to the Contentful API, that enables one to select which fields to fetch in a API request, like such:

https://cdn.contentful.com/spaces/<space_id>/entries/
    ?select=fields.productName,fields.price
    &content_type=<content_type_id>

Which returns data in this format:

  "sys": {
    "type": "Array"
  },
  "total": 1,
  "skip": 0,
  "limit": 100,
  "items": [
    {
      "fields": {
        "productName": "Whisk Beater",
        "price": 22
      }
    }
  ]
}

If I were to have a separate query, that only fetches productName, like this:

https://cdn.contentful.com/spaces/<space_id>/entries/
    ?select=fields.productName
    &content_type=<content_type_id>

I would in theory be able use the same cache entry, since all the select fields are a subset from the first query, which would save the client from having to do another network request.

I imagine it working something like this:

• Set up queryKeys that looks like this: [space_id, { content_type_id, select }], where select is a list of all the fields. In the first case, select equals ["fields.price", "fields.productName"], and in the section, ["fields.productName"]
• Define a custom queryKeyEquals function that can check on a non-serialized queryKey if they are equal. This would allow me to check if the select value is a subset of the stored cache entry. (Alternatively, we could use the meta property to check the same if we don't want to keep queryKeys non-serialized.)
• Use the select option available on useQuery to filter the fields manually.

Unfortunately there doesn't seem to be any equivalent to the queryKeyEquals available. Is this something you have been thinking of introducing, or do you have any other ideas of how I can support this use case?

[TkDodo]

hm, if the goal is to save fetches, why not just use the select option?

const useItems = (select) => useQuery('items', () => fetchItems, { select })
const useProductName = useSpaces(data => data.items.map(item => item.fields.productName))

with a proper staleTime on useItems, calls to useProductName would not trigger a fetch unless deemed necessary.

---

another idea would be to use queryClient.getQueryData inside the queryFn of useProductName that would just get the data from the queryCache of the items query, and make its own fetch if it doesn't exist.
Advantage: if data doesn't exist yet, only productName is fetched.
Disadvantage :as soon as you have items data, you'll always get it returned, so any stale time comparison would need to be done manually via dataUpdatedAt for example.

[jimmycallin]

hm, if the goal is to save fetches, why not just use the select option?

Definitely possible! But I believe this limits the implementation in some ways.

Ideally, in spirit of colocation, I want to keep which fields are necessary for the component as close to the component as possible, with an API similar to this:

// ComponentA
useProduct({fields: ["productName", "price"]})

// ComponentB
useProduct({fields: ["productName"]})

This API could be implemented using the select option as you mentioned, but then I have to store the full list of all fields in use in a third place along with the useQuery implementation.

const supportedFields = ["productName", "price"];
function useProduct({ fields }) {
  return useQuery(() => fetch(buildUrl(supportedFields)), {
    select: (data) => filterDataOnFields(data, fields),
  });
}

If I were to remove the useProduct hook from ComponentA, it will still fetch the price despite not being necessary.

If it could calculate which fields it need to fetch based on which queries are currently active, I think that would be ideal since that would ease maintainability, and also allow queries to minimize the amount of fields to fetch depending on the current view the user is seeing.

another idea would be to use queryClient.getQueryData inside the queryFn of useProductName that would just get the data from the queryCache of the items query, and make its own fetch if it doesn't exist.

That's an interesting idea that I might experiment with a little, thanks!

[TkDodo]

If it could calculate which fields it need to fetch based on which queries are currently active, I think that would be ideal since that would ease maintainability, and also allow queries to minimize the amount of fields to fetch depending on the current view the user is seeing.

yeah you can also lookup the currently active observers with queryClient.getQueryCache().findAll(key, { active: true }) or so.