take all options into account when creating hash

[olets]

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]

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.