Add Storefront properties for Product Attributes#490
Add Storefront properties for Product Attributes#490prabhuram93 wants to merge 3 commits intomagento:masterfrom
Conversation
| # See COPYING.txt for license details. | ||
|
|
||
| type Query { | ||
| customAttributeMetadata(attributes: [AttributeInput!]!): CustomAttributeMetadata @resolver(class: "Magento\\EavGraphQl\\Model\\Resolver\\CustomAttributeMetadata") @doc(description: "The customAttributeMetadata query returns the attribute type, given an attribute code and entity type") @cache(cacheable: false) |
There was a problem hiding this comment.
this is good but please change the location of your file to this file
design-documents/graph-ql/coverage/custom-attributes/attributes-metadata.graphqls
| used_in_product_listing: Boolean | ||
| position: Int | ||
| visible_on_catalog_storefront: Boolean | ||
| use_in_layered_navigation: UseInLayeredNavigationOptions |
There was a problem hiding this comment.
Perhaps name these use_in_layered_navigation, use_in_product_listing, and use_in_catalog for consistency?
There was a problem hiding this comment.
I understand these names come directly from the backend.
There was a problem hiding this comment.
Yes, the idea was to reflect the same configuration names as in the backend. So there will be consistency in dev docs too. @keharper can help with the naming.
There was a problem hiding this comment.
I'm in favor of changing used_in_product_listing to use_in_product_listing for consistency, but use_in_catalog is too dissimilar from "Visible on Catalog Pages on Storefront" to easily make the connection. I recommend changing visible_on_catalog_storefront to visible_on_catalog_pages.
There was a problem hiding this comment.
Okay. I will update it. Thanks!
Layered NavigationLooking at page https://develop.pwa-venia.com/default/venia-dresses.html?page=1, a category page on Venia. Am I correct that the proposal is that we would take the If so, it looks like the |
Product Detail PageHere's the product details query we send. Here's the fragment. Looks like we could pull this attribute_code and issue the |
Category PageHere's the category query and fragment. Looks like we'd need to add the |
SortingWe get all the aggregations in the getProductFiltersByCategory query, but we should not rely on the order of the attributes returned from GraphQL for rendering. It would be ideal to have the |
SearchUse in SearchThis setting would remain a known bug / unsupported. Attributes are always used in search. Use in Search Results Layered NavigationHere's the query for filters for the search page. We could send the Will this remain unsupported as well? |
For product attributes it should be |
I will see the feasibility of adding this in the aggregations itself without compromising the backend performance. I should be able to get the answer soon. |
we can support both these configurations. Will update the PR. |
| visible_on_catalog_storefront: Boolean | ||
| use_in_layered_navigation: UseInLayeredNavigationOptions | ||
| use_in_search_results_layered_navigation: Boolean | ||
| use_in_search: Boolean |
There was a problem hiding this comment.
I don't think this needs to be included. The way I understand it, this is more for y'all or the search team. If Use in Search is set to YES, then users can search by the product attribute values (ex: "Green"), and matching products will be included in the result set.
Venia won't do anything with this setting.
4 participants
Problem
PWA-1665
Need to control the use of product attributes on PWA Venia Storefront
Solution
Added a field storefront_properties in the customAttributeMetadata query to expose admin configuration on product attributes related to storefront.
Requested Reviewers