Release 9.1.0-canary.52

@graphcommerce/ecommerce-ui@9.1.0-canary.52

Patch Changes

• ea7af54 - Round step increment also max to two decimals as we might else get very long numbers (@paales)

@graphcommerce/magento-product@9.1.0-canary.52

Patch Changes

• abdda4c - Solve issue where Specs table values would still be shown when the value would be '0' (@paales)

Release 9.1.0-canary.51

@graphcommerce/googlerecaptcha@9.1.0-canary.51

Patch Changes

• #2537 31397f9 - Solve issue where a magento store reference was added to the graphql-mesh package. (@paales)

@graphcommerce/graphql@9.1.0-canary.51

Minor Changes

• #2537 958dcb6 - Intoduce a new Product-uid to solve an issue where cache normalization was not working properly on the frontend when viewing products with a differen curreny, etc.

  Products now have a more detailed uid which will include the scope the product is retrieved from. For example: NDg5MDM=?store=nl_NL&currencyCode=EUR. This results in a better cache normalization in Apollo Client and allows for switching between scopes (store/currency/price views/accounts) without creating a broken cache state.

  We have implemented this with a new resolver that rewrites the uid passed from Magento to the Mesh Resolver, and additing additonal data to the uid based on the headers passed from the client. This also requires each package to implement the getPrivateQueryContextMesh method to retrieve the current PrivateQuery context from the GraphQL request headers. (@paales)

@graphcommerce/graphql-mesh@9.1.0-canary.51

Patch Changes

• #2537 31397f9 - Solve issue where a magento store reference was added to the graphql-mesh package. (@paales)

@graphcommerce/hygraph-ui@9.1.0-canary.51

Patch Changes

• #2537 6e2714c - Solve issue where cached data was stale (@paales)

@graphcommerce/magento-cart@9.1.0-canary.51

Patch Changes

• #2537 1f37f05 - Forwarded ref to AddProductsToCartButton (@paales)

@graphcommerce/magento-cart-items@9.1.0-canary.51

Patch Changes

• #2537 47daa19 - Solve issue where if a product wasn't available in the cart anymore from the server the user wouldn't be able to remove the item from the cart. (@paales)

@graphcommerce/magento-graphql@9.1.0-canary.51

Minor Changes

• #2537 958dcb6 - Intoduce a new Product-uid to solve an issue where cache normalization was not working properly on the frontend when viewing products with a differen curreny, etc.

  Products now have a more detailed uid which will include the scope the product is retrieved from. For example: NDg5MDM=?store=nl_NL&currencyCode=EUR. This results in a better cache normalization in Apollo Client and allows for switching between scopes (store/currency/price views/accounts) without creating a broken cache state.

  We have implemented this with a new resolver that rewrites the uid passed from Magento to the Mesh Resolver, and additing additonal data to the uid based on the headers passed from the client. This also requires each package to implement the getPrivateQueryContextMesh method to retrieve the current PrivateQuery context from the GraphQL request headers. (@paales)

Patch Changes

• #2537 3ebd5bb - Add flushMeasurePerf for product page (@paales)

@graphcommerce/magento-store@9.1.0-canary.51

Minor Changes

• #2537 958dcb6 - Intoduce a new Product-uid to solve an issue where cache normalization was not working properly on the frontend when viewing products with a differen curreny, etc.

  Products now have a more detailed uid which will include the scope the product is retrieved from. For example: NDg5MDM=?store=nl_NL&currencyCode=EUR. This results in a better cache normalization in Apollo Client and allows for switching between scopes (store/currency/price views/accounts) without creating a broken cache state.

  We have implemented this with a new resolver that rewrites the uid passed from Magento to the Mesh Resolver, and additing additonal data to the uid based on the headers passed from the client. This also requires each package to implement the getPrivateQueryContextMesh method to retrieve the current PrivateQuery context from the GraphQL request headers. (@paales)

Patch Changes

• #2537 31397f9 - Solve issue where a magento store reference was added to the graphql-mesh package. (@paales)

@graphcommerce/next-config@9.1.0-canary.51

Patch Changes

• #2537 6492d81 - Reduce exported scope of config so we dont introduce a hidden dependency on Magento (@paales)

Release 9.1.0-canary.50

@graphcommerce/magento-category@9.1.0-canary.50

Patch Changes

• #2535 bb728e9 - Fix bug where allName would not be translated when switching stores (@Giovanni-Schroevers)

Release 9.1.0-canary.49

@graphcommerce/magento-category@9.1.0-canary.49

Patch Changes

• #2533 45c2fbb - Solve issue where in some cases a second ProductList query was made because the category used an eq filter instead of an in filter. (@paales)

@graphcommerce/magento-product@9.1.0-canary.49

Patch Changes

• #2533 dc3be1d - Solve issue when a user applies their first filter on a category page, a redundant GraphQL call would be made, even though the user was navigating to the /c/[..url] route. (@paales)

• #2533 45c2fbb - Solve issue where in some cases a second ProductList query was made because the category used an eq filter instead of an in filter. (@paales)

• #2533 88abcbf - When loading the category/search page in the case that there are no filters applied, the amount or product related queries is reduced from 2 to 1 (ProductFilters is skipped). Pagination, sorting and search terms also do not affect this. When a filter is applied we fall back to the previous functionality and do a second query to retrieve the filters.

  This did not matter when the categories/search pages were served by Magento as Magento would cache the result of the ProductFilters query. When the the catalog is served by an external service like Algolia this might be a problem.

  Implementation details: When filters are applied (e.g., filtering by color:blue), the ProductList query only returns products matching that filter, which means other filter options (like other colors) are excluded from the filter options. This behavior is expected since those other options wouldn't return any products. However, when no filters are applied, the ProductList query returns all products along with all available filter options, eliminating the need for a separate ProductFilters query. (@paales)

@graphcommerce/magento-search@9.1.0-canary.49

Patch Changes

• #2533 88abcbf - When loading the category/search page in the case that there are no filters applied, the amount or product related queries is reduced from 2 to 1 (ProductFilters is skipped). Pagination, sorting and search terms also do not affect this. When a filter is applied we fall back to the previous functionality and do a second query to retrieve the filters.

  This did not matter when the categories/search pages were served by Magento as Magento would cache the result of the ProductFilters query. When the the catalog is served by an external service like Algolia this might be a problem.

  Implementation details: When filters are applied (e.g., filtering by color:blue), the ProductList query only returns products matching that filter, which means other filter options (like other colors) are excluded from the filter options. This behavior is expected since those other options wouldn't return any products. However, when no filters are applied, the ProductList query returns all products along with all available filter options, eliminating the need for a separate ProductFilters query. (@paales)

@graphcommerce/magento-search-overlay@9.1.0-canary.49

Patch Changes

• #2533 88abcbf - When loading the category/search page in the case that there are no filters applied, the amount or product related queries is reduced from 2 to 1 (ProductFilters is skipped). Pagination, sorting and search terms also do not affect this. When a filter is applied we fall back to the previous functionality and do a second query to retrieve the filters.

  This did not matter when the categories/search pages were served by Magento as Magento would cache the result of the ProductFilters query. When the the catalog is served by an external service like Algolia this might be a problem.

  Implementation details: When filters are applied (e.g., filtering by color:blue), the ProductList query only returns products matching that filter, which means other filter options (like other colors) are excluded from the filter options. This behavior is expected since those other options wouldn't return any products. However, when no filters are applied, the ProductList query returns all products along with all available filter options, eliminating the need for a separate ProductFilters query. (@paales)

Release 9.1.0-canary.48

@graphcommerce/magento-cart-coupon@9.1.0-canary.48

Patch Changes

• #2532 4913aee - Resolve issue where a 400 error occurred due to missing coupon code data in the request. The coupon input field was being disabled before form submission, preventing the code from being included in the request payload (@joshdavenport)

Release 9.1.0-canary.47

@graphcommerce/algolia-products@9.1.0-canary.47

Patch Changes

• 499b30c - Updated used spec for API and expose the multi search endpoint. (@paales)

@graphcommerce/next-ui@9.1.0-canary.47

Patch Changes

• 4564271 - Created a revalidate method that returns a single value so that it can be overwritten centrally (@paales)

Release 9.1.0-canary.46

@graphcommerce/next-config@9.1.0-canary.46

Patch Changes

• f6b9c0d - Temporarily pin prettier to 3.5.3 to fix the GraphCommerce build: https://github.com/hosseinmd/prettier-plugin-jsdoc/pull/246/files (@paales)

Release 9.1.0-canary.45

@graphcommerce/magento-product@9.1.0-canary.45

Patch Changes

• 7d59e59 - Make sure you are able to set the defaultValue for the ProductPagePrice when running in total mode, so it works for GroupedProducts that might start with a default quantity of zero. (@paales)

• 7d59e59 - Forward inputProps for AddProductToCartQuantity (@paales)

@graphcommerce/magento-product-grouped@9.1.0-canary.45

Patch Changes

• f915f65 - Make sure the default quantity is selected on the product page for grouped products. Products are sorted correctly and create a separate GroupedProductItem fragment for easier etensibility. (@paales)

@graphcommerce/next-config@9.1.0-canary.45

Patch Changes

• f508396 - Solve issue where optional chaining for import.meta.graphCommmerce configuration paths didn't work. (@paales)

Release 9.1.0-canary.44

@graphcommerce/next-ui@9.1.0-canary.44

Patch Changes

• b423879 - DateTimeFormat, NumberFormat and RelativeTimeFormat (and all derivatives) will now wrap all number parts in a span, so that individual parts can be styled properly. (@paales)

Release 9.1.0-canary.43

@graphcommerce/magento-product-configurable@9.1.0-canary.43

Patch Changes

• f7d2bf1 - Fix build issue (@paales)