Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

take all options into account when creating hash #45

Closed
olets opened this issue Jun 29, 2024 · 3 comments
Closed

take all options into account when creating hash #45

olets opened this issue Jun 29, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@olets
Copy link

olets commented Jun 29, 2024

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

  1. 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 their options.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).

  2. 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.

d9f3a73 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.

@Zegnat
Copy link
Contributor

Zegnat commented Jul 22, 2024

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 zachleat added this to the Eleventy Fetch v5.0.0 milestone Oct 22, 2024
@zachleat
Copy link
Member

#34 was merged! 5.0.0-beta.1 is imminent

@zachleat
Copy link
Member

Notably, #34 doesn’t use all options, just method (if not GET) and request body.

@zachleat zachleat added the enhancement New feature or request label Oct 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants