Skip to content
Prev Previous commit
Next Next commit
Update custom attributes container proposal to account for attributes…
… with multiple values
  • Loading branch information
melnikovi committed Oct 20, 2020
commit 3205dd0cbfbe59b77be530e414625dcfdc7b459b
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ One workaround for "getting all fields" is based on schema introspection, it all

# Proposed solution

To account for dynamic nature of EAV attributes and the need of "getting all fields" in product search queries,we can introduce `custom_attributes: [CustomAttribute]!` container.
To account for dynamic nature of EAV attributes and the need of "getting all fields" in product search queries, we can introduce `custom_attributes: [CustomAttribute]!` container (recommended approach).
Copy link
Contributor

Choose a reason for hiding this comment

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

do fragments bring any value for PWA since we still prefer these flat single structure arrays vs infterfaces?


```graphql
type CustomAttribute {
Copy link
Member

@mslabko mslabko Oct 20, 2020

Choose a reason for hiding this comment

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

I think we have to add "type" opinion here to be able to render the appropriate template (datetime, text, multi-select, checkbox ...)

E.g.

"attributes":[
    {
      "code":"multiselect_attribute",
      "type":"multiselect",
      "values":[
            "Option 1",
            "Option 2"
      ]
    }
  ]

Copy link
Member Author

Choose a reason for hiding this comment

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

Attributes are going to be displayed as information and not as fields you can control, so I don't think it's necessary.

Copy link
Member

@mslabko mslabko Oct 22, 2020

Choose a reason for hiding this comment

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

it will be useful to render field properly on UI without complex logic. E.g. for "Date" field - "10-11-2020"

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, they are needed for the forms

Copy link
Contributor

Choose a reason for hiding this comment

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

We have this data already available in the scope of customAttributeMetadata query. Since update frequency for attribute metadata and product attribute values is different, it makes sense to separate them to avoid excessive payload size.

Expand All @@ -30,7 +30,7 @@ type CustomAttributeValue {
}
```

Alternative approach would be is to introduce an interface `custom_attributes: [CustomAttributeInterface]!`.
Alternative approach would be is to introduce an interface `custom_attributes: [CustomAttributeInterface]!`, but it seems more complicated.

```graphql
type CustomAttributeInterface {
Expand Down