What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hey guys, I'm wondering if there is something like technical product attributes, that are being pure

michael.schmetter
michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
in Help

Hey guys,
I'm wondering if there is something like technical product attributes, that are being purely used for technical reasons (product that needs special delivery, special type of product that needs a some change in checkout)?
It would mean that this information should not be shown to the customer, he only sees the consequences of those attributes (or flags) like an additional checkbox he has to click or something like that.
We could add new fields to the product for that, but that would not really be scaleable.
Another possibility would be to introduce a new property on an attribute to make it "technical", those attributes would have to be hidden on PDP and not used for searching.
Anyone an idea here?

Comments

  • U031MRXNNV7
    U031MRXNNV7 Posts: 8 🧑🏻‍🚀 - Cadet

    maybe use Strategy Pattern when running checkout process? If no information, then running default from Spryker. If yes, then attaching custom class.

  • michael.schmetter
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet

    The change could be on any part of the shop (PDP, Listing, checkout...)
    But my question is more, where to store the information, maybe someone has already learned some lessons here...

  • giovanni.piemontese
    giovanni.piemontese Spryker Solution Partner Posts: 871 🧑🏻‍🚀 - Cadet

    We could add new fields to the product for that, but that would not really be scaleable.

    why not?
    Then u have all infos everywhere...
    Of course depend how many "technical" attributes/option u have... otherwise a new relation table that every time is joined in repository..

  • UP8T3GKFH
    UP8T3GKFH Posts: 56 🧑🏻‍🚀 - Cadet

    We have made some fields on our abstract and also concrete products. We also added some of them to the mapping for ElasticSearch and also extended StorageWriter to hold the information in the desired places in Redis.
    How many fields do you need that you think it is not very scalable?

  • michael.schmetter
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet

    Around 5-10 maybe?
    Was just my gut feeling, that it maybe would be easier to use the "infrastructure" of attributes for that.

  • UP8T3GKFH
    UP8T3GKFH Posts: 56 🧑🏻‍🚀 - Cadet

    You could use the "infrastructure" of attributes, but then you have to hide them in the frontend. This could be done by a special prefix in the attribute key for example.
    And i think 10 should be no problem.

  • giovanni.piemontese
    giovanni.piemontese Spryker Solution Partner Posts: 871 🧑🏻‍🚀 - Cadet

    I would not use the "instrastructure" of attributes for some technical attr data..

  • giovanni.piemontese
    giovanni.piemontese Spryker Solution Partner Posts: 871 🧑🏻‍🚀 - Cadet

    u have then to filter out these tech attr on many feature.. Facet, Variant, Attribute Table on PDP, etc etcc...

  • michael.schmetter
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet

    Thank you for the input.
    I think I will then go with the individual fields on the product and not overengineer a general solution, if it is not used more than a few times.
    But thats exactly the conversation I was hoping to have!

Categories