[chore]: Move .graphql files from queries/ directory to the component directory where they are used

[sirugh]

Queries (and mutations) are supposed to be highly tailored to the component using them; it's not considered an optimization to reuse a query, so there's no value in keeping them in a shared folder.

Goal

• Move all .graphql from /queries directory into the directory where they are used. For example, queries/createAccount.graphql is used by the CreateAccount component so we should move the graphql file to venia-ui/lib/components/CreateAccount/.
• Ensure all tooling around queries is updated if necessary. There may be paths hardcoded to look in queries/ and if so, it needs to be updated to check all locations for .graphql instead.

Expected Structure

• Component Operations: <componentName>.gql.js - for ease of use, the default export of this file should be an object of queries and mutations. Example here.

It is expected that since multiple components imported these .graphql files, this will result in multiple components having identical operations; this is okay. Our current patterns outline that GraphQL reuse is driven by fragments, not operations, which is not a requirement in this scope. If you would like to tackle breaking response shapes into fragments, you can follow the patterns in some newer components on CartPage.

• Fragment Structure: <componentName>Fragments.gql.js

See here for more context.

[supernova-at]

Just chiming in from the Apollo caching perspective: I think this is fine, but we will want to use and share fragments to ensure we get cache hits, which may mean overfetching in some particular cases.

A good example is the Category page requesting details about a Product. To render its UI, the Category page only really needs a subset of that data (like name, small_image, price), but the PDP (a likely place the user will navigate to next) will likely want more details (media_gallery_entries, etc.).

We can create a "ProductDetails" fragment that looks something like

fragment ProductDetails on ProductInterface {
  media_gallery_entries
  name
  price
  small_image
}

and then we can re-use it in the Category and Product queries:

products {
  ... ProductDetails
}

The Category page will technically be overfetching data, but it'll make it so the PDP can serve data from the cache instead of having to make another request.

All that said, I opened an issue (magento/graphql-ce#1027) because it seems like support for fragments has some bugs in Magento GraphQL currently.

[sirugh]

Yea, so fragments may be a shareable thing but optimizing right now to create a fragment/ directory may be overkill (especially since they don't quite work). Good call out though @supernova-at !

[brendanfalkowski]

There's no value in keeping them in a shared folder.

Caveat: improves learning + onboarding new devs.

It was super nice having all queries in the same folder so I could easily compare their structure, naming, etc.

Also, I never would have noticed #1913 if the files were spread out in components.

[robdunn]

Happy to take this on. Seems like a good one to get familiar with the project. Thanks!

[awilcoxa]

@tjwiebell to fill in detail on expected pattern to follow for this issue. Also provide an example via a branch to provide a starting place.

[tjwiebell]

Given the scope of this, we're going to pull this internal as we work out the final resting place of queries and fragments.