feat: collectionStats query added

[kidunot89]

Your checklist for this pull request

Thanks for sending a pull request! Please make sure you click the link above to view the contribution guidelines, then fill out the blanks below.

🚨Please review the guidelines for contributing to this repository.

• Make sure you are making a pull request against the develop branch (left side). Also you should start your branch off our develop.
• Make sure you are requesting to pull request from a topic/feature/bugfix/devops branch (right side). Don't pull request from your master!
• Have you ensured/updated that CLI tests to extend coverage to any new logic. Learn how to modify the tests here.

What does this implement/fix? Explain your changes.

Adds collectionStats query. Here's an example usage.

Note: the query is currently in flux and without hooks for modification because it utilizes the functionality of the woocommerce-blocks Store API's ProductCollection endpoint which is still kinda limited. It works for the most part, but the attributeCounts field only takes the where.attributes field is taken into account with calculating the attribute counts. Meaning it's not possible to filter the result by any "non product attribute" taxonomies at the time of this release.

Example

query ($where: CollectionStatsWhereArgs){
  collectionStats(
    calculatePriceRange: true
    calculateRatingCounts: true
    calculateStockStatusCounts: true
    taxonomies: [{taxonomy: PACOLOR, relation: AND}]
    where: $where
  ) {
    priceRange {
      maxPrice
      minPrice
    }
    ratingCounts {
      count
    }
    attributeCounts {
      name 
      terms {
        node {
          slug
        }
        termId
        count
      }
    }
    stockStatusCounts {
      status
      count
    }
  }
}

TODO

• Add a unit test for the collectionStats query.

Does this close any currently open issues?

…

Any relevant logs, error output, GraphiQL screenshots, etc?

(If it’s long, please paste to https://ghostbin.com/ and insert the link here.)

Any other comments?

…

Where has this been tested?

• WooGraphQL Version: …
• WPGraphQL Version: …
• WordPress Version:
• WooCommerce Version:

[creative-andrew]

Thist is great! I think you are on the correct track but I would advise the following.
Instead of having the field on the Root type, it needs to be inside the Products (and Product?) field.
The collection stats depend on the query made on the product as the count of attributes changes according to it.

https://github.com/woocommerce/woocommerce-blocks/blob/trunk/src/StoreApi/docs/product-collection-data.md#product-collection-data-api

Important

In addition to the above attributes, all product list attributes are supported. This allows you to get data for a certain subset of products. See the products API list products section for the full list.

GET /products/collection-data?calculate_attribute_counts[0][query_type]=or&calculate_attribute_counts[0][taxonomy]=pa_sizes&attributes[0]&[attribute]=pa_color&attributes[0][slug]=red

would be similar to do

query GetProducts {
  products(where: {taxonomyFilter: {filters: {taxonomy: PACOLOR, terms: "red"}}}) {
    collectionStats(taxonomies: [{taxonomy: PASIZES, relation: OR}]) {
      attributeCounts {
        termId
        count
      }
    }
    nodes {
      title
    }
  }
}

The results here should be the term count of the attribute SIZES for all products that have a COLOR attribute of red

[creative-andrew]

I think we should return all the results. I don't see any type of pagination in the Store API implementation.

[kidunot89]

Because this result list can get pretty monstrous and it would be pretty foolishly to not do this. And REST is already caching the full result list so might as well take advantage of that. If you want the full list don't set any arguments, these arguments are if you actually want pagination but doesn't force it on the client

[creative-andrew]

I would consider recreating this class inside WooGraphQL plugin so we can modify it accordingly and not be subject to non-existent query params that only make sense in the REST API context.

[kidunot89]

Naw, having gone down that route with the checkout mutation. I can say with confidence this is more future-proof and easier to maintain/refactor in the likely event of a breaking change.

[creative-andrew]

Do you think we would need a filter here for extensibility?

[kidunot89]

Not at this time, because the functionality of ProductQueryFilters is kinda limited at the moment and not extendable by hooks or extra params, we can revisit this once it has been expanded upon or made extendable is some way 🤔.