Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add Storefront properties for Product Attributes #490

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Add Storefront properties for Product Attributes #490

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f873651
Add Storefront properties for Product Attributes
prabhuram93 May 6, 2021
0294d2c
Update EavGraphQl.graphqls
prabhuram93 May 10, 2021
a9e590e
Updated based on review comments
prabhuram93 May 11, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions design-documents/graph-ql/coverage/eav/EavGraphQl.graphqls
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Copyright © Magento, Inc. All rights reserved.
prabhuram93 marked this conversation as resolved.
Show resolved Hide resolved
# 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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is good but please change the location of your file to this file
design-documents/graph-ql/coverage/custom-attributes/attributes-metadata.graphqls

https://github.com/magento/architecture/pull/456/files#diff-113bf18a368d3d5c2ee6e9956737276d3f7fcc4306fe477c8dc67f937d0b8839R1

}

type CustomAttributeMetadata @doc(description: "CustomAttributeMetadata defines an array of attribute_codes and entity_types") {
items: [Attribute] @doc(description: "An array of attributes")
}

type Attribute @doc(description: "Attribute contains the attribute_type of the specified attribute_code and entity_type") {
attribute_code: String @doc(description: "The unique identifier for an attribute code. This value should be in lowercase letters without spaces.")
entity_type: String @doc(description: "The type of entity that defines the attribute")
attribute_type: String @doc(description: "The data type of the attribute")
input_type: String @doc(description: "The frontend input type of the attribute")
attribute_options: [AttributeOption] @resolver(class: "Magento\\EavGraphQl\\Model\\Resolver\\AttributeOptions") @doc(description: "Attribute options list.")
storefront_properties: StorefrontProperties
}

type StorefrontProperties {
used_in_product_listing: Boolean
position: Int
visible_on_catalog_storefront: Boolean
use_in_layered_navigation: UseInLayeredNavigationOptions
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps name these use_in_layered_navigation, use_in_product_listing, and use_in_catalog for consistency?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand these names come directly from the backend.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. I will update it. Thanks!

use_in_search_results_layered_navigation: Boolean
use_in_search: Boolean
Copy link

@supernova-at supernova-at May 11, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}

enum UseInLayeredNavigationOptions {
NO
FILTERABLE_WITH_RESULTS
FILTERABLE_NO_RESULT
}

type AttributeOption @doc(description: "Attribute option.") {
label: String @doc(description: "Attribute option label.")
value: String @doc(description: "Attribute option value.")
}

input AttributeInput @doc(description: "AttributeInput specifies the attribute_code and entity_type to search") {
attribute_code: String @doc(description: "The unique identifier for an attribute code. This value should be in lowercase letters without spaces.")
entity_type: String @doc(description: "The type of entity that defines the attribute")
}

# Additional changes made in CatalogGraphQl schema
type Aggregation @doc(description: "A bucket that contains information for each filterable option (such as price, category `UID`, and custom attributes).") {
position: Int @doc(description: "The position of attribute in layered navigation block.")
}