Comparison attributes not showing up

[themreza]

Current behavior

When you add products to the comparison page, none of the product attributes show up, even though the imported attributes have is_comparable set to true.

Expected behavior

It should correctly display the attributes marked to be shown in the comparison page.

Steps to reproduce the issue

Repository

Can you handle fixing this bug by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

• Browser:
• OS:
• Node:
• Code Version:

Additional information

To fix it, change this line https://github.com/DivanteLtd/vue-storefront/blob/master/core/modules/compare/components/Compare.ts#L13 to:

return Object.values(attributesByCode).filter((a: any) => a.is_comparable === true)

[ThomasBaier]

It is not directly a bug, it is a question of configuration.
First check that you set the attribute you want to see in the Compare is_comparable=1 in your db / elastic search.
Second configure your "default.json" || "local.json" so that "productList" and "productListWithChildren" are "includeFields" listing your attribute to compare and not listing your attribute in "excludeFields".

Example for..

1. Set price to is_comparable=1. it will be shown
2. Set your default.json to:
   "productListWithChildren": {
   "includeFields": [ "description", .... ] }
   --> to see description in comparable Listing

have fun =)

Edit:
Just to let you know, above changes leaded to an GraphQl-Error for me while asking for an description. Docker logs:

/var/www/node_modules/graphql-toolkit/dist/commonjs/epoxy/typedefs-mergers/comments.js:36
const comment = graphql_1.getDescription(node, { commentDescriptions: true });
^

TypeError: graphql_1.getDescription is not a function
at pushComment (/var/www/node_modules/graphql-toolkit/src/epoxy/typedefs-mergers/comments.ts:41:19)

[themreza]

Why use 1 and 0 when in most of the places type boolean is defined with true/false?

I think this classifies as a bug since according to the development guides, it should return true/false. Also, to adhere to the platform-agnostic guidelines, the system should uniformly follow types defined in ElasticSearch, and not in the proxy APIs (like vue-storefront-api).

Inconsistency:

https://github.com/DivanteLtd/vue-storefront-integration-sdk/blob/bf4c38771c574802159201aa62a04da6364c35eb/Format-attribute.md

vs.

https://github.com/DivanteLtd/vue-storefront-integration-sdk/blob/9093963a3c690f9ee9826c4e0c99a29afc6d8696/Dynamic%20API%20specification.md

For backward-compatibility, perhaps we can change the fix to a check that accepts 1/true and 0/false.

[ThomasBaier]

So actually you are right, magento 1 & 2 standard indexers are using true / false for there variables.

return Object.values(attributesByCode).filter((a: any) => a.is_comparable===true)
would be a good solution.

unfortunately standard data of https://test.storefrontcloud.io is not representative with 0 1 data format.

[pkarw]

@andrzejewsky