Zegnat
commented
3 months ago This is planned for version 5, as after the merge of #34, the value of options.fetchOptions.body is used for the cache key. POST requests to a GraphQL endpoint should result in separate caches.
zachleat
If I'm understanding correctly, the cache hash is based solely on the fetched url. But the response is not necessarily unique to a url. It'd be helpful if everything passed to eleventy-fetch were taken into account when creating the hash.
That would fix two problems I have when using eleventy-fetch to fetch data from a GraphQL endpoint
I have several Eleventy JS data files, each of which fetches data from the same GraphQL endpoint. The EleventyFetch calls all have the same
source; they differ only in theiroptions.fetchOptions.body. By default, each gets the same hash, and each successive data file's cache data overwrites the previous.A single massive query wouldn't work for me: I'm paginating each of the data sets separately.
For now I've worked around this by adding a unique URL query string to each data file's eleventy-fetch url (
EleventyFetch(`${process.env.MY_URL_VAR}?<data set name>`)). That's workable but brittle (and it depends on my endpoint ignoring unknown URL query content).Changing my GraphQL query doesn't bust the cached data, because the cache isn't aware of the query. When I change a query I have to delete the cache directory and then restart the dev server and/or rebuild.
https://github.com/11ty/eleventy-fetch/commit/d9f3a73bd9b52ae4a115fd4c0fd1750af3f6f2a9 looks like it may provide something a little less hacky feeling than my URL query string workaround for (1) but if I'm understanding right it's equivalently brittle and won't help (2).
Doing something like stringifying the options and including that in the hash.update data would resolve both of these.
edit: re (1): aha, I see dot notation works in
pagination.data, so I could put it all in one data file.